Azure App Serviceで特定の拠点のみアクセスを許可しようと「アクセス制限」を設定したのに、なぜか自分すら弾かれる……。
「ログストリームを見れば原因がわかるはず」と思いきや、実はここには大きな罠があります。
今回は、App Service（特にLinuxベース）を使い始めたばかりの人が必ずハマる「IP制限の正体」と、正しいトラブルシューティング術について実体験を元に解説します。
1. 罠：403エラーのログは「ログストリーム」には出ない
ApacheやNginxの感覚でいると、「アクセス拒否（403エラー）されたならログが出るはず」と考えがちです。しかし、App Serviceのログストリームをどれだけ眺めても、IP制限で拒否されたログは1行も流れてきません。
なぜ出ないのか？
App ServiceのIP制限は、アプリに届く前の「Azureのプラットフォーム階層」で遮断されるからです。
• アプリ側のログ: アプリまで到達したリクエストの記録。
• IP制限: アプリに届く前に門前払いするため、アプリ側は「アクセスがあったこと」すら知りません。
2. 解決策A：ログが見れないなら「外側」から叩く
App Service側のログが見れない状況で、私が「真の接続元IP」を特定した方法が curl や tcpping です。
「確認くん」などのWebサービスで見えるIPは、ブラウザ（プロキシ経由）のIPに過ぎません。実際の通信がどう見えているかを直接叩いて確認します。
• curlで叩く: curl -v https://your-app.azurewebsites.net
• tcpping / pspingで叩く: ポート443に対して直接疎通を確認。
私のケースでは、これらを試す中で「確認くん」とは別のIPがゲートウェイとして使われていることが判明し、そのIPを許可することで解決しました。
3. 解決策B：どうしてもログを見たいなら「診断設定」
「どうしてもAzure側で拒否されたIPの履歴を特定したい」という場合は、診断設定（AzureAppServiceHTTPLogs）を有効にする必要があります。
ただし、ここで注意したいのがコストです。
インフラチームから「Log Analyticsは高額になりがち」と釘を刺されることがありますが、これは大量のログを溜め続けると課金が膨らむためです。
• 賢い使い方: 調査時だけ有効にし、接続元IPが特定できたらすぐにオフにする。
これでコストを最小限に抑えつつ、確実に「Azureが拒否したIP」をあぶり出せます。
4. まとめ：クラウドを使いこなす「引き出し」を持とう
今回の教訓は以下の3点です。
1. IP制限のログは、アプリのログストリームには出ない。
2. Web用のIPと通信用のIPが違う可能性を疑い、curl等で直接叩く。
3. 診断設定は強力だが、コストを意識して「使い終わったら消す」のがプロの作法。
「設定したのに動かない、ログも出ない」と焦る前に、この構造を知っていれば数分で解決できます。プログラムのコードだけでなく、こうした「クラウドの仕様」を知ることこそが、開発をスムーズに進める鍵となります。