CDNやリバースプロキシ、社内プロキシを経由した通信で「どこで遅いのか」「プロキシ側で何が起きたのか」を追いたい場面は多いはずです。そんなときに役立つのがHTTPレスポンスヘッダーのProxy-Statusです。本記事では、Proxy-Statusの意味、典型的な値、使いどころ、注意点までを整理します。 Proxy-Statusは、プロキシ（中継するHTTPインターメディアリ）側の処理状況をクライアントへ伝えるためのHTTPレスポンスヘッダーです。プロキシやゲートウェイ、CDNなどが「自分はどう振る舞ったか（例: キャッシュした、接続が切れた、DNSが失敗した）」といった情報を付加し、クライアントや運用者が原因切り分けしやすくする目的で定義されています。 ポイント：Proxy-Statusは「オリジンサーバーの状態」ではなく、「途中のプロキシの状態（代理動作の結果）」を説明するためのヘッダーです。 仕様はIETFのRFCとして標準化されています。 Proxy-Statusヘッダーとは？意味や使い方をわかりやすく解説
Proxy-Statusとは
何のために使う？
Proxy-Statusの主な用途は、障害調査と性能分析です。特に、クライアントから見ると「ただ遅い」「突然切れた」ように見える事象でも、Proxy-Statusがあると中継点での状況が読み取れる場合があります。
障害切り分け
- 社内プロキシが認証・接続で失敗しているのか
- CDNがオリジンに到達できていないのか
- プロキシが途中でストリーミングを中断したのか
運用ログの補強
クライアント側（ブラウザ、アプリ、クローラー、APIクライアント）のログにレスポンスヘッダーとして残せるため、「現場で再現しない問題」でも事後分析しやすくなります。
ヘッダーの形式
Proxy-Statusは、プロキシを表す識別子（例: プロキシ名）と、結果を表すパラメータのセットで構成されます。実際の値は実装により変わりますが、読み方の基本は「どのプロキシが、どんな結果を返したか」を追うことです。
注意：Proxy-Statusの具体的なパラメータ名・意味はRFCで枠組みが定義されていますが、製品や構成によって出力内容が異なります。自社のプロキシ/CDNベンダーのドキュメントと合わせて確認してください。
ヘッダー例
以下は「イメージを掴むための例」です（値は説明用に単純化しています）。
HTTP/1.1 200 OK
Proxy-Status: edge-proxy; ok
Content-Type: application/jsonHTTP/1.1 502 Bad Gateway
Proxy-Status: edge-proxy; error="dns_failure"
Content-Type: text/html2つ目の例では、表面上は502ですが、Proxy-Statusにより「プロキシ側でDNS解決が失敗した」可能性が読み取れます（実際の分類や表現は実装依存です）。
RFC 9209では、インターメディアリがレスポンスの途中で状況変化が起きた場合、ヘッダー部を送り終えた後はトレーラーでProxy-Statusを付与できる旨が説明されています。
使い方の実務例
curlで確認する
まずはクライアントとして、レスポンスヘッダーにProxy-Statusが含まれるか確認します。
curl -sS -D - https://example.com/ -o /dev/nullアプリで記録する
APIクライアントやクローラーでは、HTTPステータスコードに加えてProxy-Statusもログに残すと、ネットワーク由来の失敗の分析が楽になります。
import requests
r = requests.get("https://example.com/api", timeout=10)
proxy_status = r.headers.get("Proxy-Status")
print("status=", r.status_code, "proxy_status=", proxy_status)監視・アラートに使う
「特定のProxy-Statusが一定回数を超えたらアラート」のように、プロキシ層の異常を早期検知できます。HTTPステータスだけでは同じ5xxに見えても、原因が「接続」「DNS」「タイムアウト」「キャッシュ」などに分かれるため、初動が速くなります。
他ヘッダーとの違い
プロキシ関連ヘッダーは複数あります。目的が違うため、混同しないことが重要です。
| ヘッダー | 方向 | 主な目的 | 信頼性の考え方 |
|---|---|---|---|
| Proxy-Status | レスポンス | プロキシ動作の結果や状態を伝える | 中継したプロキシが付与する前提。経路外から混入しない設計が必要 |
| X-Forwarded-For | リクエスト | クライアントIPなど転送情報を伝える | クライアントが偽装できるため、信頼境界の設計が重要 |
| Via | リクエスト/レスポンス | 経由したプロキシ情報を示す | 経路の可視化向き。詳細な失敗理由の表現は主目的ではない |
導入時の注意点
情報漏えいに注意
Proxy-Statusには障害原因や内部構成を推測できる情報が含まれうるため、外部に公開してよい粒度かを検討してください。社内向けAPIでは有用でも、一般公開サイトでは情報が過剰になる場合があります。
ヘッダー上書きの管理
多段プロキシ（CDN→WAF→LB→リバースプロキシ）の構成では、どの層がProxy-Statusを付けるか、複数付与されるか、上流の値を引き継ぐかを設計しておきましょう。ログ側も「どの層のProxy-Statusか」を判断できるようにしておくと運用が安定します。
トレーラーの扱い
ストリーミングや大きなレスポンスでは、状況変化がレスポンス途中に起きる可能性があります。RFCでは、ヘッダー部送信後はトレーラーでProxy-Statusを付与するケースがあり得る旨が述べられています。クライアント側がトレーラーを取得・記録できるかも確認しておくと安心です。
よくある質問
リクエストに付ける？
Proxy-Statusはレスポンスヘッダーです。クライアントがリクエストに任意に付けて意味を持たせる用途ではありません。仕様上の位置づけはRFCを参照してください。
ブラウザで見える？
開発者ツールのNetworkタブなどでレスポンスヘッダーとして確認できる場合があります。ただし、環境（ブラウザ、拡張、企業プロキシ、CORS設定）により見え方が変わる点には注意してください。
スクレイピングで役立つ？
直接「ブロック回避」になるヘッダーではありませんが、プロキシ経由で収集している場合に「失敗の原因がプロキシ側か、対象サイト側か」を切り分ける材料になります。例えば、同じ429/403でもProxy-Statusで中継側のエラーが出ていれば設定や回線の問題が疑いやすくなります。
まとめ
Proxy-Statusは、プロキシやCDNなどの中継点が「自分の処理結果」をクライアントへ伝えるためのHTTPレスポンスヘッダーです。HTTPステータスコードだけでは見えにくい原因（DNS、接続、ストリーミング中断など）の切り分けに役立ちます。一方で、公開情報の粒度や多段構成での運用設計には注意が必要です。まずはcurlやアプリログでProxy-Statusを記録し、障害対応の手がかりとして活用してみてください。
参考資料
