407 Proxy Authentication Required: 意味と直し方

プロキシからHTTP 407が返るとき、Proxy Authentication Requiredの意味を知り、資格情報、IP許可リスト、パスワードの特殊文字を確認します。

プロキシを設定し、リクエストを送ったら、ページではなく 407 Proxy Authentication Required が返りました。この案内は、ブラウザ、スクレイパー、スクリプトで有料プロキシを使い、プロキシが拒否し続ける理由を知りたい人向けです。原因は、よく出る順に歩きます。Top Proxyはプロキシサービスを比べます。IPは売らず、無料の資格情報も配らないので、以下の例はすべてプレースホルダです。

01407 Proxy Authentication Required の意味#

HTTP 407は、プロキシ認証のチャレンジです。MDNは、プロキシサーバーの「有効な認証資格情報が欠けている」ために失敗したリクエストだと説明しています（MDN, 407）。ステータスはRFC 9110、15.5.8節で定義されています。

やり取りはこう動きます。プロキシは407と、期待する方式を名指す Proxy-Authenticate ヘッダーで返します。たとえば:

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="proxy"

クライアントは、資格情報を載せた Proxy-Authorization ヘッダーでリクエストを繰り返すことになっています。つまり、一度の407は自動では失敗ではありません。最初のリクエストを資格情報なしで送り、チャレンジを受け、それから付けて再試行するクライアントもあります。問題は、クライアントがチャレンジに答えたあとも407が返り続けること、またはクライアントが答えないことです。

よく似た401と、407を分けておくと助かります。

401は、ふつう宛先が自分のログインを欲しいという意味です。プロキシのログインが通った証明ではなく、ヒントです。同じように、407はどの種類の認証が問われたかを教えますが、ステータスコードだけでは、リクエストがどこまで進んだかは証明しません。経路上のどの中継も407を返せます。設定したプロキシの前にある社内プロキシも含みます。応答が供給元のものに見えないなら、網が先に別のプロキシへ通していないかを確認してください。

番号をまったく出さないクライアントもあります。ブラウザはプロキシのログインダイアログを出し、ライブラリは失敗したトンネルと407に触れるエラーを上げることがあります。原因は同じです。

02よくある原因の一覧#

続く407の多くは、短い問題の一覧に落ちます。この表でどこから始めるかを選び、対応する節を読んでください。

期限切れプランの扱いは供給元によって違います。407を返すところも、別のエラーや閉じた接続を返すところもあるので、最後の行は除外すべきものとして扱ってください。

03まずユーザー名とパスワードを確認する#

いちばん多い原因は、いちばん単純です。プロキシが期待した資格情報を受け取っていません。この順で進めてください。

1. 資格情報を新しくコピーする。 プロキシのユーザー名とパスワードは、古いメモではなく、供給元のダッシュボードから取ってください。多くの供給元は、ダッシュボードのログインとは別のプロキシ資格情報を発行します。
2. 余計な空白を見る。 パスワードと一緒にコピーした末尾の空白や改行は見えませんが、資格情報を間違えます。
3. オプションを載せるユーザー名は作り直す。 多くのレジデンシャルとモバイルの供給元は、国コードやセッショントークンなどの指定をユーザー名へエンコードします。構文は供給元固有です。区切りが一つ違う、または未対応の値でも、ログインが拒否されます。別サービスからコピーした形式ではなく、自分の供給元の文書の形式を使ってください。
4. ホストとポートが資格情報に合うことを確認する。 供給元は製品ごとに別のゲートウェイやポートを使い、一方の資格情報が他方では動かないことがあります。
5. クライアントがどう認証するかを確認する。 ユーザー名やパスワードの欄が無いアプリもあります。システムの設定や、社内網が使うような交渉方式で認証することもあります。一部のプロキシ種類だけ資格情報に対応することもあります。チャレンジに答えられる、または答えられないと決める前に、クライアントの文書で対応するプロキシ認証方式を確認してください。

線上で何が起きているかを見るには、curlが手早い試験です。プレースホルダの値で:

curl -q -v --noproxy '' --connect-timeout 10 --max-time 30 \
  --proxy http://proxy.example.net:8000 \
  --proxy-user 'USERNAME:PASSWORD' \
  https://example.com/

-q は先頭にしてください。試験を変えうる .curlrc の既定をcurlに無視させます。--noproxy '' は、そうでなければプロキシを迂回しうる NO_PROXY 設定を上書きし、二つのタイムアウトが試験を区切ります。-v フラグはリクエストと応答のヘッダーを出すので、407とプロキシの Proxy-Authenticate ヘッダー、多くの方式ではcurlがそれに答えたかを見られます。curlの既定のプロキシ認証方式はBasicです。--proxy-anyauth は、プロキシが別のものを求めたときに適切な方式を選ばせます（curlのマニュアル）。

注意は二つです。詳細出力にはエンコードした資格情報、Cookie、トークンが入りうるので、ログを共有する前に Proxy-Authorization、Cookie、トークン値を伏せてください。コマンドラインに打ったパスワードはシェル履歴に残り、プロセス一覧に短く見えると、curlのマニュアルも警告しています。環境変数を引数へ展開しても、それは変わりません。使い捨ての試験を超えるなら、自分だけが読める設定ファイルなど、道具の保護された資格情報入力を使ってください。

この試験は、普通のTLS検証を保ちます。407のデバッグに -k や「insecure」スイッチは要りません。検証を切ってもプロキシ認証は直らず、本物の問題を隠すだけです。

04IP許可リストと、変わった外部IP#

多くの供給元は、もう一つの認証方法を出しています。公開IPアドレスを登録すると、プロキシはパスワードなしでその接続を受けます。これとユーザー名とパスワードを組み合わせられる供給元も、端点ごとに別の方法を適用する供給元もあります。許可リストには、「昨日は動いた」種類の拒否をちょうど出す失敗の形があります。供給元によっては、その拒否は407、403、落ちた接続、または別のエラーです。

プロキシが見るのは、接続の出どころのIPであり、コンピュータが自分の網カードに出すアドレスではありません。その送信元IPは、プロキシへの経路に依存します。

• 自宅とモバイルの接続は、ルーター再起動、再接続、または時間の経過だけで、新しい公開IPをよく受けます。
• NATとキャリアグレードNATでは、供給元は共有の公開アドレスを見ます。ローカルの 192.168.x.x や 10.x.x.x ではありません。
• VPN、社内網、または別のプロキシが供給元の前にあると、送信元IPはその網の出口になります。
• IPv4対IPv6。 IPv4アドレスを許可したのに接続がIPv6で供給元へ届く、またはその逆だと、プロキシはあなたを認識しないことがあります。これが当てはまるかは、供給元のゲートウェイがIPv6を受けるかによります。

確認するには、そのブラウザでプロキシを切った状態で自分のIPを開き、表示されるアドレスを供給元の許可リストと比べてください。ページは、そのブラウザからのその一つのリクエストのIPを示します。スクリプトがサーバー、コンテナ、VPN経由なら、送信元IPは違うことがあるので、失敗しているクライアントと同じ機械と網の経路から確認してください。

許可リストからパスワードへ切り替えた、またはその逆なら、いま使っている端点が、いま送っている方式を期待しているかも確認してください。

05パスワードの特殊文字#

@、:、/、#、%、? のような記号を含むパスワードは、ランダムに見える407のよくある出所です。同じ資格情報が一つの道具では動き、別の道具では失敗します。これらの文字はURLの中で意味を持ち、多くの道具はプロキシを http://user:password@host:port のような一つのURLとして取ります。

プレースホルダのパスワード p@ss:w/rd%#1 を取ってください。プロキシURLの中では、@ が資格情報の終わりとして読まれ、/、#、% が残りを切るか壊すことがあります。パスワードのリテラル : の扱いは、URLパーサーごとに違います。パーサーの動きが違うので、安全な規則は、URLへ入れる前にユーザー名とパスワードの予約文字をすべてパーセントエンコードすることです。

直し方は、道具が資格情報をどう取るかによります。

どこでも盲目にパーセントエンコードしないでください。パスワードをエンコードしてから別のパスワード欄へ打つと、プロキシは @ ではなく %40 を受け、拒否します。

curl。 マニュアルは、プロキシ文字列のユーザーとパスワードはURLデコードされると書いています。そのため @ は %40、コロンは %3a として渡せます（curlのマニュアル）。上のプレースホルダパスワードでは:

curl -q --noproxy '' --connect-timeout 10 --max-time 30 \
  --proxy 'http://USERNAME:p%40ss%3Aw%2Frd%25%231@proxy.example.net:8000' \
  https://example.com/

あるいは、プロキシURLをきれいに保ち、資格情報は --proxy-user で別に渡してください。$、!、# のような文字をシェルが解釈しないよう、値は単一引用符で囲みます。上と同じコマンドライン露出の注意は、両方の形に当てはまります。

Python。 標準ライブラリで各部分をエンコードし、それからURLを組み立てます。

from urllib.parse import quote
import requests

username = "USERNAME"
password = "p@ss:w/rd%#1"  # placeholder; load the real one from a secret store

proxy = (
    f"http://{quote(username, safe='')}:{quote(password, safe='')}"
    "@proxy.example.net:8000"
)

try:
    response = requests.get(
        "https://example.com/",
        proxies={"http": proxy, "https": proxy},
        timeout=(10, 30),  # connect timeout, read timeout
    )
    print(response.status_code)
except requests.exceptions.ProxyError:
    # Could be a 407 on the tunnel, a refused port, or another proxy failure
    print("Proxy connection failed; check the proxy address, auth, and allowlist.")

quote(..., safe='') はプレースホルダのパスワードを p%40ss%3Aw%2Frd%25%231 にし、requests はヘッダーを組み立てる前にプロキシURLからユーザー名とパスワードをデコードします。HTTPSの宛先では、トンネルを開くあいだにプロキシのチャレンジが起きるので、そこでの407は、応答オブジェクトができる前にたいてい ProxyError として出ます。ただし ProxyError は認証専用ではありません。閉じた、または間違ったプロキシポートも上げるので、メッセージは一般的なままです。例は、資格情報付きのプロキシURLを含みうる生の例外ではなく、その短いメッセージを出します。タイムアウト値は、接続と読み取りのあいだの待ちを制限します。リクエスト全体の長さの上限ではありません。証明書の検証はオンのまま（既定）で、再試行ループはありません。同じ資格情報での再試行は、407を直しません。

制御した試験で観察したこと

これらの動きを確認するため、同じ機械のローカル試験プロキシに対し、Python 3.14.4上のPython Requests 2.34.2を走らせ、ダミー資格情報（demo と、@、:、/、#、% を含むパスワード）とTLS検証オンを使いました。これはクライアントとプロトコルの動きを示すものであり、商用供給元の性能ではありません。

この試験では、HTTPProxyAuth ヘルパーは素のHTTPリクエストを認証しましたが、HTTPSトンネルは認証しなかったので、HTTPSではエンコードした資格情報をプロキシURLへ入れてください。

06修正を確かめる#

プロキシチェッカーから始めてください。プロキシの詳細を入れると、私たちのサーバーから接続し、端点が応答するかを報告します。結果は二つの留保付きで読んでください。第一に、チェッカーはあなたのIPではなく、自分のIPから接続します。供給元がIP許可リストを使い、チェッカーのIPが許可されていないなら、確認は407、403、落ちた接続、または別のエラーで拒否されることがあり、それだけでは設定が壊れている意味ではありません。第二に、成功した確認は、チェッカーの場所から端点がそれらの資格情報を受けたことを示します。ブラウザやスクリプトがプロキシを通る証明ではありません。

二番目のためには、問題のある機械からcurl試験を走らせ、設定したプロキシ経由で自分のIPを開いてください。見えるIPを、供給元があなたに渡すはずだと言う出口IP、レンジ、または端点と比べます。違うIPだけでは正しい経路の証明ではありません（VPNでも変わります）。変わらないIPだけでは、プロキシが迂回された証明でもありません。期待した出口と、クライアントが取る経路に対して確認してください。国や場所だけでも足りません。プロキシは自分の国から出ることもあります。

チェッカーは通るのにクライアントがまだ407を受けるなら、二つの経路の違いを見てください。送信元IPとIP版、端点とポート、認証方式、クライアントが特殊文字をどう扱うか、網の別のプロキシが先に答えているかです。

07別の供給元を見るとき#

上の原因を除外しても、文書化されていないユーザー名構文や分かりにくい資格情報の構成に時間を失い続けるなら、認証オプションをはっきり文書化するサービスを比べる価値があることがあります。モバイルプロキシサービスを見るか、これらのカタログ掲載から始めてください。ここに載せることは、特定のクライアントに対してどれかを試した意味ではありません。

Bright Data — レジデンシャルとデータセンタープロキシ4.41442

Bright Dataはデータ収集向けの大規模プロキシ網です。レジデンシャル、モバイル、ISP、データセンターのIPが約195か国にあります。レジデンシャルトラフィックは定期契約なしの従量払いができ、データセンターとISPアドレスは10 IPからのパックです。レジデンシャルとモバイルの利用には本人確認が必要です。

10か国

$5.00

1GBあたり

Oxylabs — レジデンシャルとデータセンタープロキシ4.0771

Oxylabsはレジデンシャル、モバイル、ISP、データセンタープロキシを、月$30からのひとつの月次契約で売っています。支払いはカード、電信送金、AliPay、PayPalです。

10か国

$0.45

1GBあたり

SOAX — レジデンシャルとモバイルプロキシ3.8218

SOAXは共有クレジットプール上のローテーションするレジデンシャルとモバイルを売り、データセンターとISPも同じプランに入ります。Builderは月$200 + VAT（200クレジット）から。Builderのティア1トラフィックは1GBあたり$3です。

85か国

$3.00

1GBあたり

Decodo（Smartproxy） — レジデンシャルとデータセンタープロキシ4.22118

Decodo（旧Smartproxy）はレジデンシャルとデータセンタープロキシを売っています。レジデンシャルは月次プランなしで1GBあたり$4、または3 GBから1GBあたり$3.75の月次パックです。支払いはカード、PayPal、Alipay、Google/Apple Pay、暗号資産（制限あり）です。

83か国

$0.38

1GBあたり

08FAQ#