プロキシ経由通信が失敗する原因と確認ポイント｜即復旧のための完全トラブルシュート手順

「インターネットには出られるのに、プロキシ経由だけ失敗する」
「特定サイトだけエラーになる」
「CONNECTで止まる」

本記事では、プロキシ通信トラブルを体系的に切り分ける方法を解説します。
この記事だけで原因特定と復旧まで実施できるよう、具体的な確認コマンドと判断基準をまとめます。

まず理解すべき：プロキシ通信の基本構造

プロキシ経由通信は以下の流れになります。

Client → Proxy → Internet Server

HTTPSの場合はさらに以下の流れになります。

• Client → Proxy (CONNECT要求)
• Proxy → Server (TCP確立)
• トンネル確立
• TLSハンドシェイク

どの段階で止まっているかを見極めることが重要です。

よくある失敗症状別チェックポイント

① プロキシに接続できない

確認項目

• プロキシIPへPing可能か
• ポート（通常3128 / 8080 / 443）が開いているか
• FWでブロックされていないか

確認コマンド（Linux）

ping 192.168.1.10
telnet 192.168.1.10 8080
nc -zv 192.168.1.10 8080

よくある原因

• ACL未許可
• FWポリシー不足
• ルーティング不整合

② CONNECTで止まる（HTTPSのみ失敗）

ブラウザで以下のようなエラーが出る場合：

• Proxy Error
• 502 Bad Gateway
• Connection refused

確認ポイント

• プロキシの上流通信は可能か
• DNS解決できているか
• SSLインスペクション設定

確認例

curl -x http://192.168.1.10:8080 https://example.com -v

ここで止まる箇所を確認します。

③ 特定サイトだけ失敗する

原因候補

• URLフィルタリング
• SNIベース制御
• 証明書検証失敗
• IPv6通信未対応

確認方法

curl -x http://proxy:8080 https://example.com -k -v

証明書エラーの場合、以下が出力されます：

SSL certificate problem: unable to get local issuer certificate

④ 認証エラー（407 Proxy Authentication Required）

確認項目

• 認証方式（Basic / NTLM / Kerberos）
• ブラウザ設定
• 認証サーバ疎通

テスト方法

curl -x http://user:password@proxy:8080 http://example.com -v

よくあるミス

• AD疎通不良
• 時刻ずれ（Kerberos失敗）
• 認証タイムアウト

通信が遅い／断続的に失敗する場合

確認すべき項目

• プロキシCPU使用率
• セッション数上限
• DNS遅延
• 上流回線輻輳

典型ログ例

Too many open files
Connection timeout
Upstream connect error

特にセッション枯渇は見落としやすいポイントです。

最短復旧のための切り分けフロー

• ProxyへTCP接続可能か確認
• DNS解決確認
• curlで直接アクセス
• curlでプロキシ経由アクセス
• 認証有無確認
• ログ確認
• 上流回線確認

直接通信が成功し、プロキシ経由のみ失敗するなら、原因はプロキシ内部です。

見落としがちな原因まとめ

• IPv6優先設定
• MTU不一致
• SSL検査証明書未配布
• 非対称ルーティング
• FWセッションタイムアウト

設計段階で防ぐポイント

• 冗長構成＋セッション同期
• 監視にセッション数を含める
• DNS監視も必須
• SSL証明書の配布自動化

まとめ

プロキシトラブルは「接続」「認証」「DNS」「上流通信」の4層で考えると整理できます。

問題箇所を段階的に特定すれば、原因は必ず見えてきます。

関連記事

• インターネットだけ遅い時の切り分け手順
• 3way handshakeで止まる時の完全診断ガイド
• FWセッションタイムアウトが引き起こす断続的通信断の正体

この記事は現場でそのまま使える実践型ガイドとして設計しています。