pingは通るのにcurlが失敗する

「サーバーには ping が通る。なのにアプリからは繋がらない」——現場で最も多い報告のひとつです。この報告が厄介なのは、ping が通ったという事実が判断を歪めるからです。「ネットワークは生きている」と結論づけてアプリ側だけを疑い始めると、実際にはファイアウォールのポート設定が原因だった、という遠回りをします。

この記事は特定のエラーメッセージの逆引きではなく、症状から犯人の層を確定させる手順を扱います。

なぜpingが通っても意味が薄いのか

ping が使う ICMP エコー要求と、アプリが使う TCP は、IP の上に乗る別のプロトコルです。ping が成功して分かるのは次の3点だけです。

• 名前解決が（ping にホスト名を渡したなら）できている
• 経路が存在し、相手ホストまでパケットが届く
• 相手ホストの OS が生きていて ICMP に応答する設定になっている

逆に言えば、そこから先はすべて未確認です。目的のポートで誰かが待ち受けているか、TLS ハンドシェイクが成立するか、アプリが正しく応答するか。これらは ping では一切分かりません。多くのファイアウォールやセキュリティグループは ICMP を許可しつつ TCP をポート単位で絞るので、「ping は通るが繋がらない」はむしろ設定として自然な状態です。

切り分けは下から順に、最初に落ちた層で止める

横にスクロール

原則はひとつです。下の層から順に確かめ、最初に失敗した層が犯人。それより上の層は見る必要がありません。

手順1: ポートが開いているか（ここで大半が決まる）

nc（netcat）でポートだけを叩きます。HTTP を喋らずに TCP の接続確立だけを見るのが要点です。

# -v 詳細 / -z 接続だけしてデータを送らない / -w タイムアウト秒
nc -vz api.example.com 443
# 成功: Connection to api.example.com 443 port [tcp/https] succeeded!

ここで失敗の仕方が決定的な情報になります。

即座に Connection refused
  → 相手ホストは生きていて、そのポートで誰も LISTEN していない
    ＝アプリ未起動／ポート番号違い／127.0.0.1 だけにバインド

数十秒沈黙して timed out
  → パケットが黙って捨てられている
    ＝ファイアウォール／セキュリティグループ／NACL の DROP

この差が生まれる理屈は単純です。ポートが閉じているだけなら相手 OS のカーネルが即座に TCP RST を返します。一方ファイアウォールの DROP は何も返さないため、こちらは SYN を再送し続け、最終的にタイムアウトします。個別のエラーの詳細はECONNREFUSEDとETIMEDOUTにまとめてあります。

手順2: TLSハンドシェイクが成立するか

ポートは開いたのに HTTPS だけ失敗する場合、TLS 層を単独で確かめます。

openssl s_client -connect api.example.com:443 -servername api.example.com </dev/null

-servername を必ず付けます。これが SNI で、1つのIPで複数の証明書を出し分けているサーバーでは、これが無いと意図しない証明書が返ってきます。「ブラウザでは見えるのにスクリプトからは証明書エラー」の典型的な正体がこれです。出力では次を見ます。

• Verify return code: 0 (ok) かどうか
• subject と issuer、そして証明書チェーンが最後まで繋がっているか
• NotAfter の日付（期限切れは驚くほど多い）

チェーンが途中で切れている場合、サーバーが中間証明書を配信し忘れています。これはブラウザでは動くのに curl やアプリからは失敗するという紛らわしい症状を生みます。ブラウザは不足した中間証明書を自前でキャッシュしたり取得したりして補完してしまうためです。詳細はSSL certificate verify failedにあります。

手順3: HTTPの応答を見る

ここまで通ったなら、残るはアプリの層です。

curl -v -o /dev/null -w '%{http_code} %{time_total}s\n' https://api.example.com/health

-v でリクエスト行とレスポンスヘッダを確認します。ここで多いのは、接続先は正しいのに Host ヘッダの振り分けで別のバックエンドに落ちているケースです。ロードバランサやリバースプロキシは Host ヘッダでバックエンドを選ぶため、IP 直打ちや /etc/hosts での上書きをすると、想定と違うアプリに届きます。

# IPは固定しつつ、正しいHost/SNIで叩く（hostsを汚さない）
curl -v --resolve api.example.com:443:203.0.113.10 https://api.example.com/health

--resolve は接続先IPだけを差し替え、Host ヘッダも SNI も正しいまま保つので、LBの特定ノードだけが壊れているといった切り分けに極めて有効です。

よくある落とし穴

アプリからだけ失敗し、curlでは成功する。 この場合ネットワークは無罪です。疑うのはプロキシ設定（HTTP_PROXY／NO_PROXY 環境変数をアプリだけが読んでいる）、コンテナ内と外での名前解決の差、アプリが使う CA バンドルの場所、そしてクライアント側のタイムアウト値です。curl は成功しても、アプリのタイムアウトが 1 秒なら 1.2 秒かかる応答は失敗します。

時々だけ失敗する。 DNS が複数のIPを返していて、そのうち1台だけが壊れている可能性があります。dig +short で全IPを列挙し、--resolve で1台ずつ叩けば特定できます。名前解決そのものが疑わしい場合は名前解決だけが遅い・たまに失敗するを参照してください。

社内からは繋がるが外からは繋がらない。 送信元IPによるフィルタ、スプリットホライズンDNS（社内と社外で違うIPを返す）、あるいは内部専用のロードバランサに向いているといった構成差を疑います。

まとめ

• ping の成功は L3 到達性の証明でしかない。目的のポート・TLS・HTTP はそれぞれ独立に失敗しうる。
• 切り分けは下から順に ping → nc -vz → openssl s_client -servername → curl -v。最初に失敗した層が犯人で、それより上は見なくてよい。
• 即 refused ならポートが閉じている、沈黙して timeout ならフィルタが捨てている。応答時間の差が最初の決め手。
• --resolve を使えば Host と SNI を正しく保ったまま接続先IPだけを差し替えられ、LBの特定ノードの故障を切り分けられる。
• curl では成功しアプリだけ失敗するなら、プロキシ環境変数・CAバンドル・タイムアウト値というクライアント側の差を疑う。