クイックアンサー
プロキシでの401 Unauthorized vs 407とは何を意味していますか?
401 Unauthorized はウェブサイトから、407 はプロキシから来ます。 CrawlRelayの住宅用プロキシ経由で401が返された場合、プロキシは認証を通過しており、ウェブサイトが独自のログインやAPIキーを要求しています。プロキシ認証情報はここでは役に立ちません。407はプロキシURLで修正し、401は対象サイトの規約に従って対処してください。
401 Unauthorized vs 407を一目で理解する
| エラー | 401 Unauthorized vs 407 |
|---|---|
| タイプ | HTTPステータスコード(4xx、クライアントエラー) |
| 送信元 | 対象のウェブサイトであり、プロキシ自体ではありません。 |
| 定義されている場所 | RFC 9110, section 15.5.2 (compare 407: section 15.5.8) |
| 再試行しますか? | いいえ。401はウェブサイト自身への認証を求めています。 |
| まず確認すること | どのサーバーが送信したか確認してください:ウェブサイト(401)かプロキシ(407)か。 |
401 Unauthorized vs 407とは何ですか?
RFC 9110でこれら二つのコードはペアになっています。401はWWW-Authenticateヘッダーを伴い、オリジンサーバーへの認証を要求します。407はProxy-Authenticateヘッダーを伴い、プロキシへの認証を求めます。応答もそれぞれ別のヘッダーに入ります:Authorizationがサイト用、Proxy-Authorizationがプロキシ用です。
どちらも「認証」と言って混同されやすいですが、ステータスコード自体が最も速い判別手段で、401はプロキシを通過していることを意味します。
a 401はPython、curl、Node.js、ブラウザではどのように表示されますか?
同じ失敗でもツールごとに異なる表示になります。ログ検索用のメッセージは以下の通りです:
- Python requests: ウェブサイトの
status_code == 401にWWW-Authenticateヘッダー付き vs プロキシの407を示すProxyError - curl: ウェブサイトの成功
CONNECT後のHTTP/2 401vs プロキシのCONNECT tunnel failed, response 407 - API:
{"message": "Unauthorized"}などのJSON本文や無効トークンメッセージ
a 401の原因は何ですか?
最も可能性が高いのは次の通りです:
- ページやAPIはログインやキーが必要です。 プロキシではなくサイトが要求しています。
- 誤った場所のプロキシ認証情報: 例えば、プロキシ向けの
Authorizationヘッダーに入れてしまっていて、サイトが拒否しています。 - 多段階フローでの期限切れのセッションCookieやトークン。
- IPや地域に紐づいたトークンで、新しい出口が無効にします。
a 401を段階的に診断するには?
- コードを確認:401はサイト、407はプロキシ。
- 以下のcurlテストを実行し、401前に
HTTP/1.1 200 Connection establishedがあるか確認。問題なければプロキシ正常。 - 通常のブラウザで同じURLがログインを要するか確認。
- 多段階フローで出口IP切替時に401が始まるか確認。
# Use the URL that fails; with https://api.ipify.org instead, you test the gateway alone.
# "HTTP/1.1 200 Connection established" first, then the site's own status: the site answered.
curl -v -x http://USERNAME:[email protected]:7777 https://TARGET_URL
# Same test through the SOCKS5 port, with DNS resolved at the exit
curl -v --socks5-hostname gw.crawlrelay.com:7778 --proxy-user USERNAME:PASSWORD https://TARGET_URLa 401をどう修正しますか?
- プロキシ問題(407)には、認証情報をプロキシURLやクライアントのプロキシ設定に入れ、
Authorizationヘッダーには入れないでください。 - キーが必要な公開APIは、サイトで登録してキーを送信してください。
- IPに紐づくセッションでは、ステッキーセッションを使ってフロー全体を維持。
- ログインが必要なコンテンツは、サイトの利用規約を確認し、自分のアカウントかつ許可された場合のみ自動処理してください。ログイン保護された個人情報のスクレイピングは当社の許容利用規約外です。
a 401の後に再試行すべきですか?
401を単純にリトライしないでください。要求に何か必要なものが欠けています。トークンやセッションを更新し、1回だけ再試行してください。繰り返し401が出る場合はコンテンツが非公開かアクセス権が切れています。
401 Unauthorized vs 407はCrawlRelayにどう関係しますか?
HTTPプロキシは自身の認証問題を407やトンネル失敗で返し、401では返しません。CrawlRelayゲートウェイ使用時に401が出る場合、リクエストはウェブサイトへ到達していることになり、問題の切り分けが速くなります。
ゲートウェイ:gw.crawlrelay.com、ポート7777(HTTP、HTTPSはCONNECT経由)、ポート7778(SOCKS5)。ユーザー名形式:USERNAME-country-{cc}-state-{state}-city-{city}-zip-{zip}-asn-{asn}-session-{id}-ttl-{minutes}。関連情報:407 Proxy Authentication Required · 403 Forbidden · Sessions guide。
401 Unauthorized vs 407:開発者がよく尋ねる質問
プロキシのパスワードが正しいのに401が出る理由は?
401はウェブサイト側の問題だからです。プロキシ認証は成功しており、サイト側がAPIキーやログインCookie、トークンなど独自の認証情報を求めています。サイトのドキュメントを確認してください。権限のないログイン保護コンテンツは自動化しないでください。
ステッキーセッションで401エラーは直りますか?
場合によっては。サイトによってはセッションやトークンが作成元のIPに紐づいており、新しい出口がトークンを無効にして401が返ります。フロー全体で1つのステッキーセッションを運用することでこれを回避できます。ただし、必要な認証情報を持たない場合は効果がありません。
HTTPリクエストのどこにプロキシ認証情報を入れますか?
プロキシURLのuser:password@部分からクライアントが構築するProxy-Authorizationヘッダー内です。ウェブサイトはこのヘッダーを見ません。プロキシが削除するためです。サイトの認証情報はAuthorizationヘッダーやCookieに入り、プロキシはそれを何もせず通します。
他のプロキシエラーのリファレンス
HTTPステータスコード
- 401 Unauthorized vs 407
- 403 Forbidden
- 407 Proxy Authentication Required
- 429 Too Many Requests
- 502 Bad Gateway
- 503 Service Unavailable
- 504 Gateway Timeout
ブラウザとクライアントのエラー
接続とTLSエラー
失敗ケースを網羅したドキュメント付きレジデンシャルプロキシ
$0.50/GB発のCrawlRelayレジデンシャルプロキシ、期限切れがないトラフィック。