クラウドでつながらないときの調べ方｜DNS・経路・LB・権限の順番
タイムアウト、refused、503、403。エラーの形はどこまで届いたかを教えてくれます。症状から層を絞る順番と、手元で確かめるコマンドを整理します。
「サイトが開かない」「API につながらない」と言われたとき、新人がまず手を付けがちなのは、知っている設定画面を上から順に開くことです。ところがクラウドの構成は、DNS、ネットワーク、ロードバランサーや CDN、権限、アプリと層が重なっていて、全部を見て回ると時間ばかりかかります。ベテランが速いのは知識の量だけでなく、エラーの形から「どの層まで届いているか」を先に読むからです。この記事では、AWS・Google Cloud・Azure に共通する調べる順番と、手元で確かめるコマンドを整理します。
エラーの形は「どこまで届いたか」を表す
リクエストは、名前解決 → 経路（ネットワーク）→ ロードバランサーや CDN → 権限の判定 → アプリ、の順に層を通ります。どこで止まったかによって、返ってくるエラーの形が変わります。逆に言えば、エラーの形を読めば、手前の層はもう通っていると分かり、調べる範囲を一気に狭められます。
| 症状 | 届いた場所 | 最初に疑う層 |
|---|---|---|
Could not resolve host / NXDOMAIN | どこにも届いていない | 名前解決（DNS のレコード、委任、TTL） |
しばらく待って Connection timed out | 途中で捨てられた | 経路（ファイアウォール、ルート、IP の取り違え） |
すぐに Connection refused | ホストまで届いた | 待ち受け（プロセス停止、ポート番号、待ち受けアドレス） |
| 502 / 503 / 504 | LB や CDN まで届いた | LB・CDN とその先のバックエンド |
403 / AccessDenied | 拒否した機器まで届いた | その機器の権限・ポリシー・ネットワーク規則 |
| 500 やアプリのエラー画面 | アプリまで届いた | アプリのログ・設定・依存先 |
タイムアウトと refused の違いは特に重要です。セキュリティグループ、VPC のファイアウォールルール、NSG などは、許可していない通信を多くの場合黙って捨てるので、送った側は応答を待ち続けてタイムアウトします。refused は、相手の OS が「そのポートでは誰も待っていない」と即座に返した状態なので、経路は通っています（途中の機器が拒否を返す設定になっている場合を除きます）。タイムアウトなのに sshd の設定や IAM を見ても、原因にはたどり着きません。
手元で層を確かめるコマンド
層ごとに、数秒で結果が出る確かめ方があります。設定画面を開く前にこれらを打てば、どの層まで正常かが分かります。
# 1. 名前解決：どの IP に解決されるかdig +short app.example.comdig +short app.example.com @8.8.8.8 # 別のリゾルバーでも同じかnslookup app.example.com # dig が無い環境（Windows など）# 2. 経路：そのポートに TCP でつながるかnc -vz -w 5 app.example.com 443 # -w 5 で 5 秒待って諦める# 3. HTTP：誰が何を返しているかcurl -si https://app.example.com/ | head -n 30 # ヘッダーと本文の先頭curl -v https://app.example.com/ -o /dev/null# DNS を飛ばして特定の IP に直接送るcurl -v --resolve app.example.com:443:203.0.113.10 https://app.example.com/dig で返った IP が想定と違えば、それより先を調べる意味はありません。nc -vz は TCP の接続だけを試すので、succeeded ならファイアウォールと待ち受けは通っており、timed out か refused かで次に見る層が決まります。Windows の PowerShell なら Test-NetConnection app.example.com -Port 443 が同じ役目を果たします。curl -v は接続先の IP、TLS のやり取り、ステータスとヘッダーを順に表示するので、どこで止まったかが 1 回で読めます。curl -I は HEAD で送るため本文が返らず、アプリによっては GET と違う応答になります。本文まで見たいときは curl -si を使います。
同じ 403 や 503 でも、返した機器によって原因の場所が違います。ALB 自身が返した応答には Server: awselb/2.0 が付き、CloudFront 経由の S3 のエラーは <Code>AccessDenied</Code> を含む XML の本文になります。HTML のエラーページか、XML か、アプリの JSON か。ステータスコードだけで判断せず、ヘッダーと本文を見て出どころを特定します。
502・503・504 は意味が違う
5xx のうち 502・503・504 は、ロードバランサーや CDN のような中継役が返すことの多いコードです。HTTP の仕様（RFC 9110）では、502 は上流のサーバーから不正な応答を受け取った、503 は一時的に処理できない、504 は上流から時間内に応答が無かった、と定義されています。どれも中継役までは届いているので、DNS や手前の経路は後回しにできます。
| コード | 意味 | よくある原因 |
|---|---|---|
| 502 Bad Gateway | 上流の応答が不正、または接続が切られた | アプリが落ちた、ポート違い、キープアライブのタイムアウトの不一致 |
| 503 Service Unavailable | 今は処理できない | バックエンドが未登録・正常なものが無い、アプリが起動できていない、過負荷 |
| 504 Gateway Timeout | 上流が時間内に応答しない | 遅いクエリ、外部 API 待ち、経路の遮断で応答が戻らない |
503 なのにアプリのアクセスログが空なら、リクエストはアプリに渡っていません。ターゲットやバックエンドの登録数と、ヘルスチェックの結果を先に見ます。504 は「遅い」と「届かない」の両方で起きるので、アプリのログに該当のリクエストが記録されているかで切り分けます。
調べる順番の 5 つの原則
- 症状が示す層から調べる。タイムアウトなら経路、refused なら待ち受け、403 なら拒否した機器の権限から見る。
- 既に正常と分かった層は後回しにする。S3 の XML が返っているなら、DNS と CloudFront までは届いている。
- 安く速く確かめられるものを先にする。タグや IP の確認は数秒、ログを読むのは数分、構成の作り直しは数時間かかる。
- 直前に変えたものを疑う。「昨日まで動いていた」なら、リリース、設定変更、作り直したリソースの差分に原因があることが多い。
- 権限を広げる・ルールを全開放する・作り直すは最後にする。原因が分からないまま入れると、直ったように見えても穴が残り、本当の原因も消える。
5 つ目は特に守りたい原則です。0.0.0.0/0 を許可するルールや、管理者相当のロールの付与は、つながるようになった瞬間に「解決」と扱われがちです。しかし公開範囲が広がったまま残り、何が原因だったかも分からなくなります。試すなら、範囲を自分の IP に絞り、終わったら戻す手順まで決めてからにします。
3 つのクラウドでの具体例
AWS：CloudFront 経由の S3 が 403 になる
非公開の S3 バケットを CloudFront の OAC（Origin Access Control）で配信していて、ディストリビューションを作り直した直後から 403 になる、というのは典型的な例です。curl -si で x-cache: Error from cloudfront が付き、本文が S3 の AccessDenied の XML なら、DNS と CloudFront は動いており、S3 がリクエストを拒否しています。
OAC 用のバケットポリシーは、AWS:SourceArn の条件で特定のディストリビューションだけを許可する書き方が一般的です。作り直して ID が変わったのにポリシーが古い ID のままなら、新しい配信からの要求は拒否されます。次に、オリジンに OAC が付いているかを見ます。なお、バケットポリシーで s3:ListBucket を許可していない構成では、存在しないパスへの要求も 404 ではなく 403 の AccessDenied になります。URL の打ち間違いやファイルの置き忘れでも同じ 403 になるので、要求したパスにオブジェクトがあるかも確かめます。ブロックパブリックアクセスを外してバケットを公開する、という対処は OAC の構成では不要で、行うべきではありません。
Google Cloud：Compute Engine の SSH がタイムアウトする
新しく作った VM に gcloud compute ssh すると Connection timed out になるのに、同じ手順で作った別の VM には入れる場合です。タイムアウトなので、鍵や OS Login の権限ではなく経路を疑います。VPC のファイアウォールルールはターゲットタグで適用先を絞れるため、許可ルールのタグと VM のネットワークタグが一致しているかを最初に見ます。ネットワーク ファイアウォール ポリシーを使っている構成なら、そちらの規則も確認します。
gcloud compute instances describe my-vm --zone asia-northeast1-b --format="value(tags.items)"gcloud compute firewall-rules list --format="table(name,direction,sourceRanges.list(),targetTags.list())"タグが合っているのに届かないなら、その VM 固有の問題として、シリアルコンソールで OS 内のファイアウォールや sshd の状態を確かめます。全 VM に 22 番を開けるルールを足すのは、ここでも最後です。
Azure：App Service がリリース直後から 503 になる
Linux の App Service でリリース直後から全リクエストが 503 になり、CPU とメモリは低いままなら、負荷ではなくアプリが起動できていないと考えます。プランのスケールアップや作り直しより先に、ログストリームで起動ログを読みます。CLI なら az webapp log tail --name my-app --resource-group my-rg で同じログを見られます。
起動ログには、モジュールが見つからない、指定したポートで応答しなかった、といった理由が出ます。当たりが付いたら、今回のリリースで変えたスタートアップコマンドやアプリ設定を確かめます。復旧を急ぐ場合は、調査と並行して前のリリースへの切り戻しを検討します。
調べた結果を書き残しながら進む
層を絞る作業は、確かめたことと結果を 1 行ずつメモしながら進めると速くなります。「dig で 203.0.113.10 に解決、nc で 443 は succeeded、curl は Server: awselb/2.0 の 503」と書いてあれば、相談された先輩はどの層が正常かを一目で読めます。「つながりません」とだけ伝えると、同じ確認を最初からやり直すことになります。
原因の見当が付いても、本番の設定を変える前に「何を、どう変えて、戻すときはどうするか」を書き、可能なら誰かに見てもらいます。調査中の思いつきで設定を次々に変えると、どの変更で直ったのか、あるいは別の障害を足したのかが分からなくなります。
問題で確かめる
この記事の内容を、制限時間つきの問題で確かめられます。
参考
- RFC 9110 HTTP Semantics
- Restrict access to an Amazon S3 origin（Amazon CloudFront 開発者ガイド）
- Troubleshoot your Application Load Balancers（Elastic Load Balancing）
- Troubleshoot connecting to your Amazon EC2 instance
- Troubleshooting SSH errors（Compute Engine）
- VPC firewall rules（Google Cloud）
- Troubleshoot HTTP 502 and 503 errors（Azure App Service）