プロキシなしで HTTP リクエストヘッダーを変更する方法(2026)
テスト 1 件に対して変更したいヘッダーは 3 つ——それのために完全な MITM プロキシを立ち上げるのは、誰もやりたくない儀式です:インストールして信頼させるルート証明書、迂回させるプロキシポート、再設定するブラウザ、そして消し忘れたときの底知れない不安。2026 年なら、ブラウザ自体が送信リクエストヘッダーをローカルで、音もなく書き換えられます——ネットワーク経路には何も入りません。以下はあなたの 3 つの選択肢の正直な地図と、それでもプロキシが正解になる場面です。
やりたいこと:どのリクエストにどのヘッダーを乗せるか
開発者が毎日行うヘッダー作業は、ブラウザがすでに発っているリクエストの上に乗っています。具体的な 3 つのシナリオ:
ステージングに対する Authorization ヘッダー。実フロントエンドが、ベアラートークンを要求するステージング API を指しています。ヘッダーを追加して、実サイトをそのまま閲覧し、認証付きのフローを観察する——コード変更なし、環境変数なし、偽ログインページなし。
X-Custom フィーチャーフラグ。バックエンドが X-Feature: new-cart のようなリクエストヘッダーで挙動を切り替えます。実サイトを普通にクリックして回る間だけ、1 つのタブだけで有効にしたい——自分のメインウィンドウや同僚のセッションを巻き込まずに。
Referer と Origin の挙動。直リンク保護、リファラーチェック、素朴な CSRF 防御の一部はこれらを読みます。あるエンドポイントが別の Referer や Origin にどう反応するかを試すには、リクエストがブラウザを出る前に編集する必要があります。
3 つとも同じ形をしています:本物の閲覧トラフィック——Cookie、JavaScript が出す fetch、アセット読み込み——その中で数行のヘッダーだけを変更する。
選択肢 1:Burp / OWASP ZAP(プロキシ)
重装備——そして時に正解。インターセプト型プロキシはすべてのリクエストとレスポンスを見て、編集・破棄・再生・差分比較を可能にし、ここにある選択肢で唯一レスポンスヘッダーも書き換えられます。代償も現実的:CA 証明書をインストールして信頼させ、ブラウザトラフィックを localhost 経由にして、影響範囲を受け入れる——プロキシをオンの間、ブラウザのあらゆる動き(触るつもりのなかったトラフィックまで)がそこを流れます。最初の有用なテストの前に、セットアップが数分を奪います。レスポンスの改ざんや Repeater 型のワークフローが絡むなら、プロキシ一択、議論の余地はありません。
選択肢 2:curl / Postman
単発のリクエストには最適:URL 1 つ、正確なヘッダー、完全な再現性。でも「これらのヘッダーを付けたまま実サイトをクリックして回る」には最悪——リクエストをブラウザからコピーした瞬間、あなたはセッションを置き去りにしています。Cookie、JavaScript が設定したトークン、リダイレクトの連鎖、アセットトラフィック、service worker、すべて計測器の外側。API 優先の仕事で curl と Postman は正しい道具であり続けますが、「閲覧そのものをテストにする」形には合っていないだけです。
選択肢 3:ブラウザ内ヘッダー拡張機能(おすすめ)
VKT Header は Manifest V3 の declarativeNetRequest セッションルールを使い、Chrome や Edge の内部でリクエストヘッダーを編集します。アーキテクチャ上の要点は、あなたとサーバーの間に何も介在しないこと。トラフィックは普段どおり Chrome のネットワークスタックを流れる——ブラウザは送信リクエストにあなたのルールをスタンプするだけです。証明書なし、プロキシポートなし、環境変数なし、消し忘れるものなし。
- プロファイル:ヘッダーのセットを保存——「Staging 認証」「フィーチャーフラグ ON」——無料なら 5 プロファイル × 各 5 ヘッダー、インポート/エクスポートでセットをマシン間にも移動できます。
- URL マッチング:プロファイルを特定 URL に紐づけ、ヘッダーが必要とされる場所に自動で付くようにする。
- タブ分離:ルールはタブ単位で適用。ステージングの鍵がほかの 11 個のウィンドウに便乗することはない。
- 自動クリーンアップ:セッションルールはタブを閉じるかブラウザを再起動すると消える。消し忘れたプロキシはインシデントですが、セッションルールは忘れようがない。
Premium($9.99 の買い切り・永久、または月額 $2.99)はプロファイルとヘッダーの上限を外し、優先サポートを追加します。Edge アドオンのストアからインストールするか、製品ページの Chrome 用インストールリンクを使ってください。正直な限界:リクエストヘッダーのみ——レスポンスヘッダーはプロキシのテリトリーのまま。
セットアップ・適用範囲・クリーンアップ:3 つの選択肢を比較
| 基準 | Burp / ZAP | curl / Postman | VKT Header |
|---|---|---|---|
| セットアップの手間 | 証明書インストール + プロキシ迂回;数分 | なし——ただしブラウザの外 | インストール + ワンクリック |
| 適用範囲 | オンの間の全ブラウザトラフィック | ツールから送ったリクエストのみ | 1 タブ、または URL マッチしたタブ |
| レスポンスヘッダー | 可——完全インターセプト | 該当なし——閲覧しないから | 不可——リクエストヘッダーのみ |
| クリーンアップ | 手動;消し忘れが危険源 | 何も残らない | 自動——タブを閉じると全ルールが消滅 |
| 費用 | 無料(請求書はあなたの時間) | 無料枠/有料プラン | 無料 5×5;$9.99 買い切りの Premium |
それでもプロキシを使うべきとき
正直な役割分担を。道具は仕事に向けるために存在するのです:レスポンスの変更——古い Cache-Control を押しつける、Set-Cookie を無力化する、CORS ヘッダーの書き換え——が必要なら、拡張機能ではできず、プロキシならできます。リクエストの再生と差分比較、1 バイト変えて同じフローを 50 回流すなら、Burp Repeater や ZAP がその仕事の天職。深いセキュリティテスト——スキャン、インターセプト、フロー全体の改変——なら、許可された範囲の中でプロキシを正しく使うべきです。拡張機能の仕事はもっと狭い:自分の送信リクエストヘッダーを、タブに限定し、タブを閉じたら消す。その狭さがまさに要点で、儀式ゼロのワークフローはそれで手に入ります。
よくある質問
プロキシをインストールせずに HTTP ヘッダーを変更できますか?
できます。VKT Header のような Manifest V3 拡張機能は declarativeNetRequest を使います:ブラウザが自分の通常ネットワークスタックの内部で、送信リクエストヘッダーを直接編集する——設定するプロキシも、インストールする証明書もなく、トラフィックは今まで通りサーバーへ直行します。
これらのヘッダーはレスポンスヘッダーにも効きますか?
VKT Header では効きません——リクエストヘッダー専用です。サーバーの返り値(Set-Cookie、Cache-Control、CORS)の書き換えはインターセプトの領域:そこは Burp や ZAP が本当に必要になる仕事です。
自分のトラフィックは誰かのサーバーを経由しますか?
しません。VKT Header はローカルファースト:ルールとプロファイルは端末内に留まり、アップロードゼロ、アカウントなし、アナリティクスなし——拡張機能が要求するのは declarativeNetRequest と storage の 2 つの権限だけです。
タブを閉じたらルールはどうなりますか?
設計どおり、消えます。VKT Header は declarativeNetRequest のセッションルール上に構築されていて、タブを閉じるかブラウザを再起動すると消去されます——テスト用のヘッダーが来週も静かにオンのまま、ということは起きようがありません。
無料枠に制限はありますか?
無料プランは 5 プロファイル × 各 5 ヘッダーまで——URL マッチング、タブ分離、インポート/エクスポートを含みます。Premium は $9.99 の買い切り・永久(好みで月額 $2.99 も可)で上限を外し、優先サポートを追加します。
私たちの見解:プロキシは対話全体をインターセプトする;ヘッダー拡張機能は、通常の閲覧をしながら自分の送信行にスタンプを押すだけ。この記事のきっかけとなった「ヘッダー 3 つの変更」テストには、VKT Header が儀式ゼロの答えです:タブ単位、URL マッチ、自動消滅、無料で開始——そして仕事がレスポンスや再生に育ったとき、起動すべき道具はもう分かっているはず。
その他の VKT ツールは拡張機能カタログに。または [email protected] まで。
