プロキシ407の切り分け方：`--proxy-anyauth`と資格情報を安全に確認する

プロキシ経由の通信で407が返った場合、直ちにIPの交換や追加購入へ進むのではなく、まずプロキシ認証の設定を確認します。プロキシは407（Proxy Authentication Required）とProxy-Authenticateヘッダーによって認証チャレンジを返せるためです（RFC 7617）。

最初に確認する順序

最初に、407応答のProxy-Authenticateで提示された方式を確認します。次に、資格情報が「取得先サーバー用」ではなく「プロキシ用」として設定されているかを見直します。

curlでは、取得先サーバーの資格情報に使う-uと、プロキシの資格情報に使う-Uが区別されています（curl公式チュートリアル）。入力先を取り違えている場合は、IPを変更しても認証設定の問題は残るため、先に指定先を修正するのが合理的です。

認証方式をcurlに選択させる場合、プロキシ認証では--proxy-anyauthを使用します。取得先サーバー向けの--anyauthとは用途を分けてください（curl公式マニュアル）。--proxy-anyauthは応答ヘッダーを確認して方式を選ぶため、追加のネットワーク往復が発生する可能性があります。また、再送時にデータを巻き戻せない標準入力からのアップロードには適しません（curl公式マニュアル）。まずGETなどの小さな疎通確認を行い、アップロード試験は別工程に分けると判断しやすくなります。

Basic認証で見落としやすい点

Basic認証の資格情報は、ユーザーID、コロン、パスワードを連結し、そのデータをBase64でエンコードして生成します（RFC 7617）。Base64は暗号化ではありません。TLSなど外部の安全な仕組みと併用しない限り、安全なユーザー認証方式とは見なされません（RFC 7617）。Basic資格情報はプロキシへのProxy-Authorizationヘッダーで送信できます（RFC 7617）。

ユーザーIDにはコロンを含められず、最初のコロン以降はパスワードとして扱われます（RFC 7617）。発行されたIDを転記したのに認証できない場合は、余分な空白だけでなくコロンの有無も確認対象にします。

資格情報を残さない調査方法

curlの-vは通信の詳細を表示し、--traceや--trace-asciiはさらに詳しい内容をファイルへ記録できます（curl公式チュートリアル）。調査では便利ですが、保存内容を無条件に共有する運用には向きません。URL、シェル履歴、プロセス一覧、CIログ、トレースファイルへ資格情報が混入していないかを確認し、必要な結果だけを記録します。

資格情報をコマンドラインへ直接書かず、curlの設定を標準入力から読ませれば、オプションがプロセステーブルへ表示されるのを避けられる場合があります（curl公式チュートリアル）。記録する項目は「407の有無」「提示された方式」「プロキシ用設定の適用有無」「認証後の成否」に絞り、秘密そのものは残さない運用が適切です。

判断基準と向いていない条件

設定修正後に接続できたなら、IPの追加購入より認証設定の是正を優先できます。反対に、TLSなどの保護なしでBasic認証を使う構成は、機密性や価値のある情報を守る用途には向きません（RFC 7617）。

--proxy-anyauthによる追加往復を許容できない処理、再送不能な標準入力アップロード、ログの閲覧範囲を制限できない環境にも不向きです。407を調べる際は、「プロキシが提示した方式」「資格情報の指定先」「通信経路の保護」「秘密が残る場所」の順に確認すると、購入判断と設定不良を切り分けやすくなります。