プロキシサーバーとは？仕組み・種類・Windowsでの設定と確認方法
プロキシサーバーとは、利用者のPCとWebサーバーの間に入り、通信を代わりに中継するサーバーのことです。
この記事では、仕組みと種類、Windowsやブラウザでの設定と確認方法、つながらないときの対処までを図で解説します。
この記事は以下のような人におすすめ！
- プロキシサーバーの仕組みと種類を基礎から知りたい人
- 会社のPCでプロキシの設定を確認・変更したい人
- 「407」などのエラーでWebにつながらず困っている人
プロキシサーバーとは
1-1. 通信を代わりに中継するサーバー
プロキシ（proxy）は英語で「代理」という意味で、プロキシサーバーは利用者の代わりにWebサーバーとやり取りをするサーバーです。
HTTPの仕様を定めたRFC 9110では、プロキシを「クライアントが、通常はローカルの設定によって選び、リクエストを受け取って処理を試みる、メッセージの転送役」と説明しています（参考1）。
つまり、利用者のPCはWebサーバーへ直接つなぐのではなく、まずプロキシへリクエストを送り、プロキシがそれを受けてWebサーバーとやり取りします。
次の図は、利用者のPC・プロキシ・Webサーバーの3者の間で、通信がどの順番で流れるかを示したものです。
図の上段のように、HTTPの通信では、PCからプロキシ、プロキシからWebサーバーという2つの接続に分かれます。
RFC 9110も、仲介者を通るリクエストは途中で別々の接続を通ると説明しており、Webサーバーが直接やり取りする相手はプロキシになります（参考1）。
そのため、Webサーバー側で接続元として見えるのは、通常は利用者のPCではなくプロキシのIPアドレスです。
ただし、プロキシの設定によっては元の利用者の情報が相手に伝わることもあるため、プロキシを「完全に身元を隠す道具」と考えるのは正しくありません。
1-2. HTTPとHTTPSで中継のしかたが違う
いまのWebサイトの多くはHTTPSで暗号化されているため、プロキシは通信の中身を読まずに中継する方法も持っています。
それが、図の下段にある「CONNECT」というHTTPのメソッドです。
RFC 9110によると、CONNECTは受け取った相手に宛先のサーバーへのトンネルを作るよう求め、成功したあとは閉じるまで双方向のデータをそのまま転送させるメソッドです（参考1）。
CONNECTのリクエストには、「www.example.com:443」のように宛先のホスト名とポート番号だけを書き、ポート番号は省略できません（参考1）。
トンネルができると、1つ以上のプロキシを通してエンドツーエンドの仮想的な接続ができあがり、その接続はTLSで保護できます（参考1）。
トンネルは、メッセージを変えずに2つの接続の間を中継する「目隠しの中継役」として定義されています（参考1）。
このため、HTTPSの通信では、プロキシは基本的にWebページの中身を見ることはできませんが、どのホストのどのポートへつないだかは分かります。
HTTPではプロキシが代わりにリクエストを送り、HTTPSではCONNECTで作ったトンネルを通して暗号化された通信をそのまま中継すると覚えると、仕組みを整理しやすくなります。
1-3. プロキシを使う目的
RFC 9110は、プロキシは組織のHTTPリクエストを共通の仲介者に集め、セキュリティサービスや共有キャッシュなどに使われることが多いと説明しています（参考1）。
会社や学校のネットワークでプロキシが使われる主な目的は、次の3つです。
- アクセス制御：業務に関係のないサイトや危険なサイトへの接続を止める
- 記録と監査：誰がいつどのサイトへアクセスしたかのログを残す
- キャッシュ：よく見られるページを保存し、表示を速くして回線の負担を減らす
キャッシュについては、HTTPキャッシュの仕様であるRFC 9111が、複数の利用者で再利用する「共有キャッシュ」は通常、仲介者の一部として置かれると説明しています（参考2）。
同じ仕様は、HTTPキャッシュの目的を、以前の応答を再利用して性能を大きく高めることだとしています（参考2）。
これに対して、1人の利用者専用の「プライベートキャッシュ」は、多くの場合ブラウザなどの中に組み込まれています（参考2）。
応答にprivateという指示が付いているときは、共有キャッシュは原則としてその応答を保存しません（参考2）。
ログインした人ごとに内容が変わるページがプロキシのキャッシュから別の人へ返されないよう、サーバー側でキャッシュの指示を正しく付けておくことが大切です。
キャッシュの仕組みと導入方法はキャッシュサーバーの記事で、通信を通すかどうかを決める別の仕組みはファイアウォールの記事で解説しています。
プロキシサーバーの種類
2-1. フォワードプロキシとリバースプロキシ
プロキシサーバーは、どこに置かれ、誰のために中継するかによって、大きくフォワードプロキシとリバースプロキシに分けられます。
次の図は、2つの置き場所と目的の違いを並べたものです。
フォワードプロキシは、社内ネットワークなど利用者側の出口に置かれ、利用者の代わりにインターネット上のサイトへアクセスします。
一般に「プロキシサーバー」というと、このフォワードプロキシを指すことが多く、1-1で見たRFC 9110の「クライアントが選ぶ」プロキシもこちらにあたります（参考1）。
導入の流れやメリットは、次の記事でくわしく解説しています。
リバースプロキシは、Webサーバーの手前に置かれ、利用者からのアクセスをいったん受け取ってから、背後のサーバーへ転送します。
RFC 9110では「ゲートウェイ（リバースプロキシ）」と呼ばれ、利用者からはWebサーバーそのものに見えながら、受け取ったリクエストを別のサーバーへ転送する仲介者とされています（参考1）。
同じ仕様は、ゲートウェイがキャッシュによる高速化や、複数のサーバーへの負荷分散などによく使われると説明しています（参考1）。
RFC 9110は、ゲートウェイが利用者側との通信では、元のWebサーバーと同じHTTPの決まりに従う必要があるとしています（参考1）。
利用者は普通のURLにアクセスするだけなので、自分のPCでリバースプロキシを設定する必要はありません。
構成例や導入手順は、次の記事で解説しています。
2-2. 透過型プロキシ・Webプロキシ・クラウドプロキシ
利用者が何も設定しなくても通信が経由するプロキシは、透過型プロキシ（インターセプトプロキシ）と呼ばれます。
RFC 9110は、透過型プロキシはクライアントに選ばれるのではなく、外向きのTCPポート80などの通信をネットワーク側でふるい分けたり転送したりするものだと説明しています（参考1）。
同じ仕様によると、公衆のネットワークで利用登録を済ませるまでインターネットを使わせない仕組みや、社内のファイアウォールで利用ルールを守らせる目的でよく使われます（参考1）。
ただし、送信者に知られずに通信を扱う仲介者は、プロトコルの上では通信を盗み見る攻撃者と区別できず、セキュリティや互換性の問題を生むこともあると注意されています（参考1）。
このほか、ブラウザから専用のサイトを開いて別のサイトを表示するWebプロキシや、プロキシの機能をクラウドのサービスとして提供するクラウドプロキシもあります。
種類ごとの違いを、表にまとめます。
| 種類 | 置き場所 | 利用者の設定 | 主な目的 |
|---|---|---|---|
| フォワードプロキシ | 利用者側の出口 | 必要（手動または自動） | アクセス制御・ログ・キャッシュ |
| リバースプロキシ | Webサーバーの手前 | 不要 | 負荷分散・キャッシュ・サーバーの保護 |
| 透過型プロキシ | ネットワークの途中 | 不要 | 利用ルールの適用・利用登録 |
| クラウドプロキシ | クラウド上 | 必要（エージェントや自動設定） | 場所を問わないアクセス制御 |
プロキシサーバーのメリットと注意点
3-1. 主なメリット
プロキシサーバーを使うメリットは、通信を1か所に集めることで、管理と効率の両方を高められる点にあります。
1つめは、社内の通信をまとめてチェックできることで、危険なサイトへの接続を止めたり、問題が起きたときにログから経緯をたどったりできます。
2つめは、キャッシュによる高速化で、RFC 9110はキャッシュが以前の応答を保存し、応答時間と回線の使用量を減らすと説明しています（参考1）。
3つめは、Webサーバーから見える接続元がプロキシになるため、社内のPCのアドレスを外部に直接見せずに済むことです。
リバースプロキシの場合は、負荷分散やキャッシュに加え、古いシステムや信頼できないサービスを内側に隠す目的でも使われます（参考1）。
3-2. 知っておきたい注意点
一方で、すべての通信がプロキシを通るため、プロキシが止まったり混雑したりすると、社内全体でWebが見られなくなるおそれがあります。
プロキシを冗長化したり、監視したりして、止まりにくくしておくことが大切です。
次に、HTTPSの中身まで検査したい場合は、プロキシで暗号を一度ほどいて調べるSSLインスペクションが必要になります。
ただし、検査によって安全な接続が成り立たなくなるサービスもあり、Microsoftの資料も、Defender for Endpointのクラウド接続にはTLSの検査を使わないよう求めています（参考5）。
検査を導入するときは、対象から外す通信の一覧を作っておく必要があります。
最後に、インターネット上で誰でも使える無料の公開プロキシには注意が必要です。
RFC 9110は、転送する途中でメッセージや内容を書き換えるように作られたプロキシもあると説明しています（参考1）。
運営者の分からないプロキシを通すと、暗号化されていない通信を読まれたり書き換えられたりするおそれがあり、これは中間者攻撃と同じ危険です。
会社のPCのプロキシ設定は、情報システム部門が管理していることがほとんどなので、自分の判断で変更したり、公開プロキシに切り替えたりしないようにしましょう。
Windows・ブラウザでの設定と確認方法
4-1. Windowsには2種類のプロキシ設定がある
Windowsでプロキシを確認するときに最初に知っておきたいのは、プロキシの設定が1つではないということです。
次の図は、Windowsの中にある2種類の設定と、プロキシの決まり方をまとめたものです。
1つは、ブラウザなどが使うユーザーのプロキシ設定で、Internet Explorerの時代から「インターネット オプション」で管理されてきたもの（WinINet）です。
もう1つは、Windowsのサービスやサーバー向けのアプリが使うWinHTTPのプロキシ設定です。
Microsoftの資料は、Defender for EndpointのセンサーがLocalSystemの権限で動いてWinHTTPを使って通信し、WinHTTPの設定はWinINetのプロキシ設定とは独立していると説明しています（参考5）。
同じ資料は、Defender Antivirusのクラウド保護についても、証明書の失効リストを取得できるシステム全体のWinHTTPプロキシを優先するよう勧めています（参考5）。
そのため、「ブラウザではWebが見られるのに、Windowsのサービスやセキュリティ製品だけがつながらない」というときは、WinHTTP側の設定を疑う必要があります。
ユーザー側の設定は、Windows 10やWindows 11では「設定」の「ネットワークとインターネット」にある「プロキシ」の画面から確認できます。
画面の名前や配置はWindowsのバージョンによって異なることがあるため、見つからない場合は「設定」の検索欄に「プロキシ」と入力すると探しやすくなります。
4-2. 自動設定（WPAD・PAC）と手動設定
プロキシの指定方法には、アドレスとポートを直接入力する手動設定と、設定を自動で取得する方法があります。
自動で取得するしくみの1つがWPAD（Web Proxy Auto-Discovery）で、Microsoftの資料はWinHTTPもブラウザと同じくこのプロトコルに対応していると説明しています（参考3）。
WPADでは、DHCPやDNSを使ってPAC（Proxy Auto-Configuration）ファイルのURLを見つけ、そのファイルをダウンロードします（参考3）。
PACファイルはスクリプトで、リクエストのたびに宛先のURLとホスト名を渡してFindProxyForURLという関数を実行し、使うプロキシの一覧を求めます（参考3）。
宛先にプロキシを通さず直接つなげる場合は、特別な値を返して直接接続を指示します（参考3）。
WinHTTPが対応するPACファイルのURLはhttp:とhttps:だけで、file:のURLには対応していません（参考3）。
また、WinHTTPが扱えるPACファイルは、ECMAScriptで書かれたスクリプトに限られます（参考3）。
ダウンロードしたPACファイルは、PCにキャッシュされることもあります（参考3）。
なお、同じ資料は、WPADの仕様が「Internet-Draft」の段階から進まないまま2001年5月に期限切れになったことも注記しています（参考3）。
PACファイルの書き方や動作確認の方法は、次の記事で解説しています。
手動設定では、プロキシのアドレスとポートに加えて、プロキシを通さない宛先（例外、バイパス）を指定するのが一般的です。
社内のWebサイトなどを例外にしておかないと、本来は直接つながる社内サイトまでプロキシを経由し、表示できなくなることがあります。
4-3. コマンドとブラウザで確認する
WinHTTP側の設定は、コマンドプロンプトでnetshというコマンドを使って確認・変更します。
Microsoftの資料によると、netshのwinhttpコンテキストでWinHTTPのプロキシとトレースを設定でき、以前のProxyCfg.exeの代わりに使うよう案内されています（参考4）。
いまの設定を表示するには、次のコマンドを実行します。
netsh winhttp show advproxy以前から使われている「netsh winhttp show proxy」は非推奨になっており、資料はshow advproxyを使うよう求めています（参考4）。
ブラウザ側の設定をWinHTTPへ取り込みたいときや、プロキシを使わない状態に戻したいときは、次のコマンドを使います（参考4）。
netsh winhttp import proxy source=ieこのコマンドは、Internet Explorerのインターネット オプションにあるプロキシ設定をWinHTTPへ取り込みます（参考4）。
netsh winhttp reset proxyこのコマンドは、WinHTTPのプロキシを直接接続（DIRECT）に戻します（参考4）。
プロキシを直接指定する例として、Microsoftの資料は「netsh winhttp set proxy 10.0.0.6:8080」を挙げ、この設定は既定のWinHTTPプロキシを使うすべてのアプリとサービスに影響すると注意しています（参考5）。
ただし、set proxyも非推奨で、新しいset advproxyではJSON形式で、プロキシ、例外、PACファイルのURL、自動検出の有無を指定します（参考4）。
set advproxyでは、設定を利用者単位（user）にするかコンピューター単位（machine）にするかを選べますが、SOCKS5には対応していません（参考4）。
set proxyの例外リストに、localを半角の山かっこで囲んだ特別な値を指定すると、ドメイン名を付けない短い名前のホストをすべてプロキシの対象から外せます（参考4）。
Microsoftの資料は、設定するときはコマンドプロンプトを「管理者として実行」で開くよう案内しています（参考5）。
会社のPCではグループポリシーなどで管理されていることが多いため、変更する前に管理者に相談しましょう。
ブラウザのMicrosoft Edgeは、組織がポリシーでプロキシの設定方法を決められるようになっています。
EdgeのProxySettingsポリシーでは、ProxyModeとして、プロキシを使わないdirect、システムの設定を使うsystem、自動検出のauto_detect、固定のサーバーを使うfixed_servers、PACファイルを使うpac_scriptを選べます（参考6）。
このポリシーが有効なときは、Edgeはコマンドラインで指定したプロキシのオプションを無視し、ポリシーが設定されていなければ利用者が自分で設定を選べます（参考6）。
ProxySettingsポリシーは、Windowsではグループポリシーの「管理用テンプレート」の「Microsoft Edge」にある「Proxy server」で設定し、レジストリではSOFTWARE\Policies\Microsoft\EdgeのProxySettingsという値に保存されます（参考6）。
このポリシーはWindowsとmacOSではEdgeのバージョン77以降で使え、iOSには対応していません（参考6）。
ブラウザで見られるかどうかと、netsh winhttp show advproxyの結果の両方を確認すると、どちらの設定に原因があるかを切り分けやすくなります。
プロキシでつながらないときの対処
5-1. エラーの番号から原因を考える
プロキシを経由した通信がうまくいかないとき、ブラウザに表示されるHTTPのステータスコードは原因を探す大きな手がかりになります。
代表的なエラーと、RFC 9110の定義、確認するポイントを表にまとめます（参考1）。
| 表示 | RFC 9110での意味 | まず確認すること |
|---|---|---|
| 407 Proxy Authentication Required | プロキシを使うために、クライアントの認証が必要 | プロキシのユーザー名・パスワード、サインインの状態 |
| 502 Bad Gateway | プロキシやゲートウェイが、先のサーバーから不正な応答を受け取った | 接続先のサーバーの状態、プロキシの先の経路 |
| 504 Gateway Timeout | プロキシやゲートウェイが、先のサーバーから時間内に応答を受け取れなかった | 接続先の混雑・停止、プロキシとサーバーの間の通信 |
407が表示された場合、プロキシはProxy-Authenticateというヘッダーで認証方法を示し、クライアントはProxy-Authorizationヘッダーを付けてリクエストし直すことができます（参考1）。
多くの場合はブラウザが認証画面を出すので、社内のアカウント情報を入力するか、パスワードを変更した直後なら保存されている古い情報を更新します。
502や504は、プロキシやゲートウェイが、その先のサーバーとのやり取りで問題を受けたことを示しています（参考1）。
RFC 9110はリバースプロキシもゲートウェイの一種としているため、このエラーは社内のプロキシだけでなく、Webサイト側に置かれたリバースプロキシが返している場合もあります（参考1）。
切り分けの目安として、特定のサイトだけで起きるなら相手のサイト側の問題の可能性が高いので時間をおいて試し、複数のサイトで起きるなら社内のプロキシを疑って管理者に確認してもらいましょう。
応答に含まれるViaヘッダーは、途中で転送したプロキシやゲートウェイの情報を順番に記録するもので、どこを経由したかを調べる手がかりになることがあります（参考1）。
WinHTTPを使う処理の原因をくわしく調べたいときは、netsh winhttp set tracingでトレースを有効にして、通信のログを残すこともできます（参考4）。
5-2. 切り分けの手順
エラーの番号が出ない場合も含め、次の順番で確認すると原因を絞り込みやすくなります。
- つながらないのはブラウザか、サービスやアプリかを確かめる
- ブラウザなら、Windowsの「設定」でプロキシの指定を確認し、組織のポリシーで決められている場合は管理者に確認する
- サービスなら、netsh winhttp show advproxyでWinHTTPの設定を確認する
- 自動設定を使っている場合は、PACファイルのURLに手が届くかを確認する
- 社内サイトだけがつながらない場合は、例外（バイパス）の設定を確認する
PACファイルを使う設定では、ファイルが取得できないときの動きにも注意が必要です。
EdgeのProxyPacMandatoryという設定は、PACスクリプトが無効または取得できない場合に、直接接続へ切り替えないようにするものです（参考6）。
この設定が有効な環境では、PACファイルのサーバーが止まるとWebに接続できなくなるため、管理者がPACファイルの配布元を確認する必要があります。
また、Defender for Endpointの資料は、システム全体の固定のWinHTTPプロキシは、ネットワーク構成が変わらない端末に向いているとしています（参考5）。
ノートPCのように社内と自宅を行き来する端末で固定のプロキシを設定すると、社外ではプロキシに届かずにつながらなくなることがあります。
VPNを使っていて社内と社外の通信の分け方が気になる場合は、スプリットトンネルの記事も参考にしてください。
よくある質問とまとめ
6-1. よくある質問
Q1. プロキシサーバーとは簡単にいうと何ですか？
利用者のPCとWebサーバーの間に入り、利用者の代わりに通信を中継するサーバーで、会社のネットワークではアクセス制御やキャッシュのために使われます。
Q2. プロキシとVPNの違いは何ですか？
プロキシは主にWebの通信をアプリの単位で中継する仕組みで、VPNはPCと接続先の間に暗号化された通信路を作ってネットワークごと社内につなぐ仕組みという違いがあります。
Q3. 自分のPCのプロキシ設定はどこで確認できますか？
ブラウザなどが使う設定はWindowsの「設定」のプロキシの画面で、サービスが使うWinHTTPの設定はコマンドプロンプトの「netsh winhttp show advproxy」で確認できます（参考4）。
Q4. 「407 Proxy Authentication Required」と表示されたらどうすればよいですか？
プロキシを使うための認証が求められている状態なので、社内のユーザー名とパスワードを入力し直し、解決しない場合は管理者にアカウントの状態を確認してもらいましょう（参考1）。
Q5. 無料の公開プロキシを使っても大丈夫ですか？
運営者が分からないプロキシでは、暗号化されていない通信の中身や、どのサイトへ接続したかが運営者に知られてしまうため、ログインや個人情報の入力が必要なサイトでは使わないほうが安全です。
VPNでつながらないときの確認ポイントは、VPNに接続できないときの対処法の記事で解説しています。
6-2. まとめ
プロキシサーバーは、利用者とWebサーバーの間に入って通信を代わりに中継し、HTTPSではCONNECTで作ったトンネルを通して暗号化された通信をそのまま中継します。
利用者側の出口に置くフォワードプロキシ、サーバー側の入口に置くリバースプロキシ、設定なしで通る透過型プロキシがあり、目的によって使い分けられます。
Windowsにはブラウザなどが使う設定と、サービスが使うWinHTTPの設定の2種類があり、WinHTTP側はnetsh winhttp show advproxyで確認できます。
つながらないときは、407なら認証、502や504ならプロキシの先のサーバーというように、エラーの番号から確認する場所を絞り込みましょう。
まずは自分のPCのプロキシ設定がどうなっているかを、この記事の手順で確かめるところから始めてください。
参考1：RFC 9110 HTTP Semantics（RFC Editor）
参考2：RFC 9111 HTTP Caching（RFC Editor）
参考3：WinHTTP AutoProxy Support（Microsoft Learn）
参考4：Netsh.exe commands（Microsoft Learn）
参考5：Configure proxy connectivity for Microsoft Defender for Endpoint on Windows（Microsoft Learn）
参考6：Microsoft Edge Browser Policy Documentation ProxySettings（Microsoft Learn）
