こんな悩みはありませんか
「アクセス制限やアクセスログのためにクライアントのIPアドレスを取得したいけれど、request.ipとrequest.remote_ipのどちらを使えばいいのか分からない」「本番環境に出したらIPアドレスがロードバランサーのものになってしまった」——Railsでこうした経験をしたことがある方は少なくないはずです。
IPアドレスの取得は一見単純な処理に見えますが、プロキシやCDNを経由する構成では正しく実装しないと簡単に偽装されてしまうという落とし穴があります。この記事では、Railsに組み込まれている仕組みを使って、クライアント判別を安全に行うための実装手順と注意点をまとめました。
この記事でできるようになること
本記事を読むことで、Rails標準のActionDispatch::RemoteIpミドルウェアの役割を理解し、trusted_proxiesを適切に設定してIPアドレスのなりすましリスクを減らせるようになります。あわせて、CDNやロードバランサー経由の環境で起きがちな「意図しないIPが取れる」問題への対処法も押さえられます。
具体的な手順
ステップ1：request.ipとrequest.remote_ipの違いを理解する
Railsのコントローラ内では、request.ipとrequest.remote_ipという2つの方法でIPアドレスを取得できます。request.ipは接続元の生のIPをほぼそのまま返すのに対し、request.remote_ipはActionDispatch::RemoteIpミドルウェアによってフィルタリングされた、より信頼性の高い値を返します。
クライアント判別や不正アクセス対策で使うなら、基本的には request.remote_ip を使うのが安全です。
ここを混同したまま実装してしまうケースは意外と多く、正直なところ「両方ある理由を知らずに何となく使っていた」という方も多いのではないでしょうか。まずはこの違いだけでも覚えておくと安心です。
ステップ2：trusted_proxiesを設定する
ActionDispatch::RemoteIpは、X-Forwarded-Forヘッダーの値をそのまま信用するのではなく、config.action_dispatch.trusted_proxiesに登録されたIPレンジからのリクエストだけを「信頼できるプロキシ」として扱う仕組みになっています。
# config/application.rb
config.action_dispatch.trusted_proxies = [
IPAddr.new("10.0.0.0/8"),
IPAddr.new("192.168.0.0/16")
]
ループバックアドレスやプライベートネットワークのレンジはデフォルトで信頼済みとして扱われますが、自社のインフラ構成に合わせて明示的に設定を見直すことが重要です。ここは一度設定して終わりではなく、インフラ構成が変わるたびに見直すべきポイントだと感じます。
正直なところ、trusted_proxiesの設定はインフラ担当と連携しないと正確な値が分からないことが多いです。アプリ側だけで完結させようとせず、ネットワーク構成図を見ながら確認するのがおすすめです。
ステップ3：CDNやロードバランサー環境での確認
CloudflareやAWSのALB／ELB、Herokuのようなプロキシを経由する構成では、リクエストが複数のプロキシを通過してからアプリケーションに届きます。この経路上のプロキシをすべてtrusted_proxiesに含めていないと、remote_ipがプロキシ自身のIPを返してしまい、本来知りたいクライアントのIPが取得できなくなります。
最初にこの現象に遭遇すると「バグでは」と戸惑いやすいポイントです。まずは本番相当の環境で実際にrequest.remote_ipをログ出力し、想定通りのIPが取れているかを確認する習慣をつけると安心できます。
ステップ4：IPアドレスに依存しすぎない設計にする
X-Forwarded-Forヘッダーはクライアント側で自由に値を設定できるため、信頼できるプロキシを経由していない限り、IPアドレスは偽装され得る情報だという前提を忘れてはいけません。
IPアドレスだけをアクセス制御やレート制限の根拠にせず、他の手段と組み合わせて判定するのが現実的な対策です。
実務では、rack-attackのようなレートリミット用のgemやCDN側の検証機能と併用し、IPアドレスは「参考情報の一つ」として扱う設計にしているケースをよく見かけます。IPアドレス単体で完璧な判別をしようとすると、どうしても無理が出てくる印象です。
セキュアな実装方法について、金融機関の事例も参考になります → 金融機関でClaude・Gemini・ChatGPTを導入するには？セキュリティ要件を満たす実装ステップ
つまずきやすいポイントと対処
開発環境ではrequest.ipとrequest.remote_ipが同じ値になることが多く、違いに気づかないまま本番にデプロイして初めて問題が表面化するケースが目立ちます。ローカルではプロキシを経由しないため当然といえば当然なのですが、ここは意識していないと見落としがちです。
また、trusted_proxiesの設定漏れに気づかず、「監査ログに記録されているIPがどれも同じ値になっている」という状態に長期間気づかなかった、という声も耳にします。定期的にログを見直す習慣をつけておくと、こうした事故を早めに発見できます。
注意：IPアドレスは個人情報として扱われる場合があるため、ログへの保存期間やアクセス権限についても、セキュリティポリシーに沿った運用を確認しておきましょう。
AI連携時のセキュリティ対策についてはこちらで詳しく解説しています → AIに「ホームディレクトリ全削除」をされないために。自動化導入前に確認すべき安全チェックリスト
まとめ
RailsでクライアントIPを取得する際は、request.remote_ipを基本としつつ、trusted_proxiesを自社のインフラ構成に合わせて正しく設定することが、なりすまし対策の第一歩になります。あわせて、IPアドレス単体に頼りすぎない設計を意識することで、より安全なクライアント判別が実現できるはずです。まずは今の本番環境でremote_ipが想定通りの値を返しているか、一度確認してみてはいかがでしょうか。
コメント