トラブルシューティング · 実用ガイド
curl error 7「Failed to connect」？ファイアウォール変更前に接続先・経路・待受を確認
エラー7は接続段階の失敗を示すだけです。実際のホップ、実行環境、ソケット結果を保存してから修正します。
curl error 7 は libcurl がホストまたはプロキシへ接続できなかったことを示しますが、ファイアウォールが原因とは限りません。
元の要求と詳細ログを固定し、失敗した環境で再現し、拒否・タイムアウト・経路なしを分けて責任境界だけを変更します。
実際の接続ホップを固定する
再試行前に引数、URL、作業ディレクトリ、実行主体、完全なエラーと curl -v の接続行を保存し、ホスト、ポート、解決先、プロキシ選択を記録します。
最初の比較でコマンドを短縮しません。URL、プロキシ変数、既定ポートが変われば別の接続試行です。
失敗した実行環境で再現する
元のコンテナ、サービスアカウント、ジョブランナー、アプリケーションホストで同じ限定テストを実行します。
プロキシ環境、curl 設定、アドレス族、ネットワーク名前空間を保存します。Docker の事例は同じ名前でも異なるアドレスへ到達し得ることを示します。
拒否・タイムアウト・経路なしを分類
ECONNREFUSED、ETIMEDOUT、ENETUNREACH は異なる修復分岐です。具体的な接続結果を失わないでください。
同じ環境で対象と既知の正常な宛先を一つずつ試し、一つのポートから全体の障害を推測しません。
接続先と待受を確認する
管理下のサービスが期待ポートとアドレス族で待受しているか確認し、公開された接続先と実際の待受を比較します。
複数アドレスがある場合は curl の試行順を保存します。IPv4 成功は IPv6 側の失敗を消しません。
プロキシの最初のホップを分ける
プロキシ選択時、最初の TCP 接続はプロキシです。同じ環境からそのホップを確認し、成功後に対象サイトを評価します。
組織全体のプロキシを削除せず、適用された変数、設定、送信元ポリシーを記録して一つだけ可逆変更します。
元の要求で終了確認する
同じ URL、プロキシ選択、実行環境で元のコマンドを繰り返し、接続先、応答、接続時間、終了コードを記録します。
責任が不明、露出が広がる、他チーム所有の場合は停止し、アドレス、ポート、結果、時刻を引き渡します。
