curl が HTTP_PROXY を無視する理由

curl が HTTP_PROXY を意図的に例外扱いする理由、プロトコル別の変数、ALL_PROXY、環境変数による代理接続テストを予測しやすくする方法を説明します。

HTTP の宛先には、小文字の http_proxy を設定します。curl は大文字の HTTP_PROXY を意図的に無視します。POSIX シェルでは次のように指定します。

http_proxy=http://127.0.0.1:8080 curl http://example.com/
https_proxy=http://127.0.0.1:8080 curl https://example.com/

これらの代入は、直後のコマンドにだけ適用されます。例の待ち受け先を自分のプロキシに置き換えてください。公開エンドポイントを比較するなら、HTTP プロキシ一覧から候補を選べます。https_proxy 変数は HTTPS の宛先への経路を選びます。値が http:// なら、それは依然として宛先へのトンネルを作成できる通常の HTTP プロキシを意味します。PowerShell や Windows のコマンドシェルでは代入の構文が異なります。

この大文字表記が危険な理由

CGI 環境は受信したリクエストヘッダーを大文字の HTTP_ 変数に変換することがあります。そのため、Proxy というヘッダーが HTTP_PROXY になり得ます。それを送信接続の設定として信頼すると、リクエストのデータにプロキシを選ばせることになります。curl が小文字を要求するのは、この対応付けを避けるためです。この例外は HTTPS や他のプロトコル変数には同じ形では適用されません。

変数を変更しても経路が変わらない場合

まずプロトコル固有の変数を調べ、その後にフォールバックの ALL_PROXY を確認します。一致する NO_PROXY ルールがあると、プロキシを迂回できます。小文字の変数や競合する定義も影響します。次の Unix 系シェルのループは、認証情報を含み得る値を表示せず、変数が存在するかだけを報告します。

for name in http_proxy HTTP_PROXY https_proxy HTTPS_PROXY all_proxy ALL_PROXY no_proxy NO_PROXY; do
  if printenv "$name" >/dev/null; then
    printf '%s is set\n' "$name"
  fi
done

表示された定義をローカルで調べてください。定義が復活する場合は、起動元のシェル、サービス、IDE、コンテナー、CI の設定を確認します。存在の確認で分かるのは入力の候補であり、どの値が優先されたかではありません。

これらのプロキシ選択から一つのリクエストを切り離すには、エンドポイントと空の迂回リストの両方を指定します。

curl --proxy http://127.0.0.1:8080 --noproxy '' --connect-timeout 5 --max-time 15 --verbose https://example.com/

直接接続が許可されている場合の比較は次のとおりです。

curl --noproxy '*' --connect-timeout 5 --max-time 15 --verbose https://example.com/

これらのコマンドは、継承した経路と接続障害を切り分けるのに役立ちます。環境設定をさらに変更する前に、プロキシのテスト結果を段階ごとに読み解いてください。curl の変数規則は curl に適用するものです。アプリケーション自身のランタイムでは、プロキシの検出や設定の統合方法が異なる場合があります。

関連記事