トラブルプロキシネットワーク運用 Microsoft Edge Windows 11 トラブルシューティング curl 情シス

【保存版】プロキシ環境でサイトが開かない時の切り分け5手順とEdge裏技

公開: 2026年9月5日

※本記事には広告を含みます。

はじめに

社内のプロキシ環境下で、ユーザーから「特定のWebサイトや社内システムだけが開かない」「申し訳ございません。このページに到達できませんと表示される」という障害報告を受けた際、原因がクライアントPC、プロキシサーバー、DNS、あるいは相手先Webサーバーのどこにあるのか分からず、切り分けに手間取った経験はないでしょうか。

私も駆け出しのころ、ブラウザのリロードを繰り返したり、あちこちの設定を闇雲に変更したりして時間を溶かしてしまった苦い経験があります。

プロキシを経由するWeb通信は、名前解決（DNS）やTLSハンドシェイク、プロキシ認証が絡み合うため、レイヤーごとに順序立ててパケットの到達状況を確認しないと、真の原因に辿り着けません。

この記事では、プロキシ環境でWebサイトに繋がらないときに「どこまで通信が到達しているか」を正確に突き止める5段階の切り分け手順と、Microsoft Edgeをプロキシなしで起動して直接テストする裏技コマンドを徹底解説します。

読み終えるころには、障害の発生箇所を数分で特定し、的確なエスカレーションや復旧作業ができるようになります。

この記事の要点

プロキシ障害の切り分けは「プロキシ自体の疎通」「名前解決」「TLSハンドシェイク」「HTTPステータス」の順に段階的に行う
curl.exe -v -x コマンドを使用することで、TLSのSNIやプロキシとのCONNECTネゴシエーションを丸裸にできる
Microsoft Edgeに --no-proxy-server オプションを付けて起動することで、端末の全体設定を汚さずにプロキシ迂回テストが可能である

項目	動作確認・検証環境
検証年月	2026年3月
対象OS	Windows 11 Pro 23H2・24H2
検証ツール	PowerShell, `curl.exe`, `Test-NetConnection`, Microsoft Edge
実行権限	一般ユーザー権限（一部コマンドは管理者推奨）

結論：プロキシ障害を5分で特定する5段階切り分けフロー

結論からお伝えすると、プロキシ環境でのWeb接続トラブルは 「以下の5つのステップを順番に実行し、どこで通信が途切れたか」 を特定するのが最も論理的で無駄がありません。

[ステップ1: プロキシへのTCP到達性確認]  --> そもそもプロキシサーバーが生きていてポートが開いているか？
                ↓ OK
[ステップ2: 名前解決（DNS）の確認]       --> プロキシ側、またはクライアント側でIPが引けているか？
                ↓ OK
[ステップ3: curlによるTLS/CONNECT調査]   --> HTTP CONNECTメソッドやSSL証明書検証で弾かれていないか？
                ↓ OK
[ステップ4: Edgeプロキシなし直接起動]    --> プロキシを完全にバイパスした場合にサイトは開くか？
                ↓ OK
[ステップ5: PACファイル / 例外設定点検]  --> クライアントのルーティング判定ミスがないか？

【実践手順】現場で使える調査コマンドと出力ログの読み解き方

各ステップで実行する具体的なコマンドと、結果の判定方法です。

ステップ1：プロキシサーバーへのTCPポート疎通確認

まず、社内プロキシサーバー自体と通信できているかを確認します。

# プロキシのIP/ホスト名とポート番号（8080等）を指定してテスト
Test-NetConnection -ComputerName "proxy.corp.local" -Port 8080

TcpTestSucceeded : True: プロキシサーバーまでのネットワーク経路は正常です。
TcpTestSucceeded : False: 社内LANの切断、プロキシサービスの停止、またはローカルFWによる遮断が疑われます。

ステップ2：curl.exeによるプロキシ経由の詳細通信ログ確認

Windows 10/11に標準搭載されている curl.exe を使い、詳細ログ（Verboseモード）で接続します。

curl.exe -v -x http://proxy.corp.local:8080 https://target-site.example.com

ログから判明する障害ポイント

HTTP/1.1 407 Proxy Authentication Required:
プロキシの認証エラーです。ドメインパスワードの期限切れやシングルサインオン（Kerberos/NTLM）の失敗が原因です。
HTTP/1.1 403 Forbidden:
プロキシのURLフィルタリング（カテゴリブロック）によって意図的に遮断されています。
schannel: SEC_E_UNTRUSTED_ROOT または SSL certificate problem:
プロキシのSSLインスペクション（通信復号化）証明書が、クライアントの信頼されたルート証明機関にインストールされていません。
HTTP/1.1 502 Bad Gateway / 504 Gateway Timeout:
プロキシサーバーから先のインターネット回線、または相手先Webサーバーがダウンしています。

【裏技】Microsoft Edgeを「プロキシなし」で直接起動して検証する

「プロキシの不具合なのか、相手先Webサイト自体の障害なのか」を切り分ける最も手っ取り早い方法は、「プロキシを完全無効化して直接アクセスしてみる」 ことです。

しかし、Windowsのプロキシ設定をオフにしてしまうと、社内の他の通信に影響が出たり、GPOで設定がロックされていて変更できない場合があります。

コマンドライン引数「--no-proxy-server」の活用

コマンドプロンプトや「ファイル名を指定して実行（Win + R）」から以下のコマンドを実行します。

msedge.exe --no-proxy-server https://target-site.example.com

このコマンドで起動したEdgeウィンドウは、OSのプロキシ設定やPACファイルを完全に無視し、直接インターネットへパケットを送信 します。

このEdgeでサイトが開く場合 → 社内プロキシやPACファイルの設定不備が確定。
このEdgeでも開かない場合 → 相手先サーバーの障害、または社内ファイアウォールでの直接通信遮断が確定。

※検証時は、起動済みのEdgeプロセスと混ざらないよう、一度既存のEdgeをすべて閉じてから実行するか、別プロファイルディレクトリ（--user-data-dir="C:\Temp\EdgeTest"）を指定して起動するとより確実です。

よくある質問（FAQ）

Q: 「申し訳ございません。このページに到達できません（接続が切断されました）」とブラウザに出る原因は？

A: プロキシサーバーが相手先サーバーとTLSハンドシェイクを行おうとした際に、相手先から「TCP RST（リセットパケット）」が返ってきたか、TLSのバージョン（TLS 1.2/1.3）や暗号スイート（Cipher Suite）の不一致でネゴシエーションが決裂したケースが代表的です。前述の curl.exe -v でエラー詳細を確認してください。

Q: Google Chromeでも「--no-proxy-server」は使えますか？

A: はい、Chromium共通のオプションであるため、chrome.exe --no-proxy-server でも全く同様にプロキシをバイパスして起動できます。

まとめ

プロキシ環境におけるWeb接続トラブルの切り分け手順は以下の通りです。

闇雲に設定を弄らず、「TCP疎通 → 名前解決 → TLS/CONNECT → HTTPステータス」 の順に追跡する
ブラウザの抽象的なエラー画面ではなく、curl.exe -v -x の生ログ から真のエラー原因を突き止める
msedge.exe --no-proxy-server を活用し、OS設定を変えずにプロキシ要因とWebサーバー要因を瞬時に切り分ける
SSL証明書エラーが出ている場合は、プロキシのルート証明書配布状況を確認する

この論理的なトラブルシューティングフローを身につけることで、突発的なネットワーク障害にも冷静かつ最速で対応できるようになります。

免責規定

この記事で提供される情報は、一般的なガイダンスを目的としており、すべての環境やシステムでの動作を保証するものではありません。

OSのバージョンやリリースによっては、記載されている事が実行できない、または異なる結果をもたらす可能性があります。
また、会社所有のパソコン、スマホ、タブレットなどでは、ポリシーや権限によって実行できない場合があります。

この記事の情報を使用することによって生じる問題や結果について、筆者およびサイト管理者は責任を負いません。
すべての操作は自己責任で行ってください。

最後までお読みいただきありがとうございました。
またお会いしましょう！