Windows Server 2016/2019 で netsh winhttp set proxy により WinHTTP のプロキシを設定したのに、ファイアウォールログ上では Public IP 宛てに TCP 80/443 の通信試行が大量に出続ける――。IP をブロックしても宛先が変わって再試行されるこの現象を、実務で困らない切り分け手順と「止める」ための現実的な進め方で整理します。
現象の整理：プロキシ設定済みなのに Public IP 宛てに 80/443 が飛ぶ
検証用ラボ内の Windows Server 2016/2019（VM）で、以下のように WinHTTP のプロキシを設定しているにもかかわらず、ファイアウォールログで多数の Public IP 宛ての TCP 80/443 が観測されるケースがあります。
netsh winhttp set proxy x.y.z.w:8080さらに、特定の IP をブロックしても別の IP に切り替えて再試行され、ログも止まらない。ここで押さえるべきポイントは次の2つです。
- この時点では「通信の正体」を断定できない（OS 機能・更新系・証明書検証・診断送信・アプリ独自実装など可能性が広い）
- 「IP を塞ぐ」だけでは根本解決になりにくい（宛先が CDN や負荷分散で変わる、FQDN が複数IPを返す、時間帯で変動する等）
コミュニティ回答でも、最終的に推奨される最短ルートは「どのプロセス／サービスが通信しているかを先に突き止める」です。深掘りが必要な場合は Microsoft サポート案件として調査する、という流れになります。
まず押さえる前提：WinHTTP プロキシが効く範囲と“効かない通信”
「WinHTTP のプロキシを入れた＝Windows の外向き通信が全部プロキシ経由になる」と思いがちですが、実際はそうならないことがあります。Windows の通信は大きく分けると以下の系統があり、どのスタック／API を使っているかでプロキシの効き方が変わるためです。
| 分類 | 主な利用者 | 主な設定場所 | プロキシが効かない/外れる典型パターン |
|---|---|---|---|
| WinHTTP | サービス・システムコンポーネント（例：一部の更新・検証系） | netsh winhttp set proxy | アプリが WinHTTP を使っていない／独自実装で直結 |
| WinINET（ユーザー系プロキシ） | ユーザーコンテキストのアプリ、IE/旧Edge系の設定依存アプリ | インターネットオプション / ユーザーのプロキシ設定 | サービス（LocalSystem）は WinINET のユーザー設定を参照しない |
| アプリ独自（HTTPライブラリ/ソケット直叩き） | 一部エージェント、ベンダーツール、ミドルウェア、独自アプリ | アプリ固有（設定ファイル、環境変数、GUI設定等） | プロキシ未対応／バイパス実装／PAC 未対応 など |
ファイアウォールログに「プロキシ IP（x.y.z.w）」ではなく「外部の Public IP」が大量に出ている場合、ざっくり言えば次のどれかです。
- その通信を出しているプロセスが WinHTTP の設定を見ていない（別スタック、または直結）
- HTTP(S) に見えて実はプロキシ不要の方式で接続している（実装上は 80/443 を使うが HTTP/HTTPS ではない等もあり得る）
- プロキシ設定は入っているが、例外（バイパス）や別設定が優先されている
このため、いきなり「宛先IP一覧を作って全部ブロック」という動きよりも、発信元（プロセス）を掴むのが最短です。
IP ブロックが“いたちごっこ”になりやすい理由
ログ上で宛先 IP が変わり続ける場合、次のような要因が典型です。
| よくある要因 | 起こること | IP ブロックが効きにくい理由 |
|---|---|---|
| CDN / 負荷分散 | 同一サービスでも接続先 IP が多数存在 | 1つ塞ぐと別IPへ切替、数十〜数百IPが候補になる |
| DNS 応答の変動 | 同一FQDNでも時間帯・場所で応答IPが変わる | 固定の deny リストが追従できない |
| 複数エンドポイントへのフェイルオーバー | 第一候補が失敗すると第二、第三…へ | ブロックしても“試行”自体は続く |
| 失敗時のリトライ設計 | 一定間隔で再試行（バックオフしつつ継続） | 止めない限りログが出続ける |
つまり「外向き通信を止めたい」の“止める”には2種類あります。
- 物理的に出さない：ネットワーク／FW で遮断する（試行ログは残る可能性）
- 試行そのものを発生させない：原因プロセス／サービスの設定変更・無効化・代替構成にする（理想だが、原因特定が必須）
この記事は後者（試行そのものを止める）に近づけるための、現場向けの手順を中心に説明します。
最優先：どのプロセスが通信しているかを特定する
コミュニティ回答でも最初に推奨されるのがここです。プロセス名（できれば実行ファイルパス）と PID を取ることができれば、そこから設定・ポリシー・サポート問い合わせまで一気に前進します。
| 手段 | 強み | 弱み / 注意点 | 向いている状況 |
|---|---|---|---|
| リソース モニター | GUIで早い、プロセス名まで見える | 瞬間的な試行だと捕まえにくい | いま発生中、継続的に出ている |
netstat -ano / PowerShell | 追加ツール不要、PID が取れる | 確立前の試行は拾えないことがある | 接続が一定時間維持される |
| WFP 監査ログ（イベント） | ブロックされた通信も記録できる | 監査設定が必要、ログ量が増える | FWで落としているため接続が確立しない |
| Sysmon | プロセス・宛先・ポートが高精度で残る | 導入/運用が必要、ログ設計が重要 | 再現待ち、長時間観測したい |
| ETW/パケットキャプチャ | 最終手段として情報量が多い | 解析負荷が高い、フォーラムでは範囲外になりがち | どうしても正体が掴めない |
リソース モニターで確認する
まずは最短です。通信が継続しているタイミングで実施します。
resmon.exeを起動- 「ネットワーク」タブを開く
- 「TCP 接続」や「リッスンしているポート」付近で、リモート アドレス（Public IP）やポート（80/443）を目視
- 該当行の イメージ（プロセス） と PID をメモ
ここでプロセス名が出れば勝ちです。もし捕まえられない場合は、次の「ブロックされた通信をイベントで取る」へ進みます。
コマンドで PID→プロセス名を突き止める
接続が確立している（あるいは一定時間維持される）場合、netstat が有効です。
netstat -ano | findstr ":80 "
netstat -ano | findstr ":443 "特定の宛先 IP が分かっているなら、それで絞ります。
netstat -ano | findstr "203.0.113.10"PID が取れたら、プロセス名へ変換します。
tasklist /FI "PID eq 1234"PowerShell でパスまで見たい場合の例です（管理者で実行）。
Get-Process -Id 1234 | Select-Object Id,ProcessName,Pathただし、ファイアウォールで遮断している場合は「確立した接続」が残りにくく、netstat では捕まえられないことがあります。その場合は次の監査ログが強力です。
ブロックされている通信なら「監査ログ」でプロセスを出す
Windows のブロックログ（テキストの firewall.log）だけでは、プロセス名が出ないことがあります。そこで、Windows Filtering Platform（WFP）の監査イベントを有効にし、ブロックされた通信に紐づくアプリ情報を得ます。
環境により項目名が異なるため、ポイントだけ押さえてください。
- ローカル セキュリティ ポリシー（または GPO）で、フィルタリング プラットフォーム関連の監査を有効化
- イベント ビューアーの「セキュリティ」ログに、通信ブロック（例：5157系）として残る
コマンド派なら auditpol で状況確認・有効化の導線を作れます（サブカテゴリ名は OS 言語で差が出るため、まず一覧から当てるのが安全です）。
auditpol /list /subcategory:* | findstr /i "Filtering Platform"
auditpol /list /subcategory:* | findstr /i "フィルタリング"イベントで「どのアプリ（パス）」「どのサービス」「どの宛先」に対してブロックされたかが取れれば、原因は一気に絞れます。
| ログの種類 | 得られる情報 | おすすめ用途 |
|---|---|---|
| Windows Defender Firewall ログ（テキスト） | 宛先IP/ポート/許可・拒否 など | 「何が起きているか」の俯瞰 |
| セキュリティ監査（WFPイベント） | プロセス/アプリ情報、場合によりユーザー/サービス | 「誰が出しているか」を特定 |
長期観測なら Sysmon を使う
再現性が低い、あるいは「一定間隔で勝手に出る」タイプは Sysmon が便利です。Sysmon のネットワーク接続イベント（一般に Event ID 3）には、プロセス名、PID、宛先IP/ポートが残ります。
ただし、導入するとログが増えるため次を意識してください。
- 収集対象を絞る（全通信を取るのではなく、80/443 や特定プロセス中心にする）
- 保持期間と転送先（SIEM 等）を決める
- 検証後はルールを整理して“常設に耐えるログ量”にする
「フォーラムではパケットや詳細ログ解析は範囲外」とされることが多いため、Sysmon や WFP 監査で プロセス特定まで持っていけると、相談やサポート依頼もスムーズになります。
最終手段：ETW/パケットキャプチャで裏取りする
どうしてもプロセスが掴めない場合は、netsh trace などで ETW トレースを取り、通信発生点を追います。これは解析の手間が増えるため、Microsoft サポート案件にする前提で「材料として採取」する用途が現実的です。
netsh trace start capture=yes tracefile=C:\temp\nettrace.etl persistent=no maxsize=512
# 再現させる（数分〜）
netsh trace stop採取した ETL をどう解析するかは環境により異なるため、運用手順が固まっていない場合はサポートに持ち込むのが無難です。
発信元が svchost.exe だった場合：中身の「どのサービス」かまで掘る
特定できたプロセスが svchost.exe の場合、そこで止めると行き詰まります。svchost.exe は複数サービスを束ねる“入れ物”であり、どのサービスが外向き通信しているかまで追う必要があります。
まずは PID をキーに、svchost 内のサービス一覧を出します。
tasklist /svc /FI "PID eq 1234"PowerShell でサービス名と表示名、起動種類まで見たい場合の例です。
Get-WmiObject Win32_Service | Where-Object { $_.ProcessId -eq 1234 } |
Select-Object Name, DisplayName, StartMode, Stateここまで来ると、次の判断ができます。
- 明らかに必要なサービス（例：更新、証明書検証、セキュリティ製品の定義更新等）→ “止める”ではなく内部配信・内部参照へ切替を検討
- ラボでは不要なサービス（例：診断送信、外部接続の健全性チェック等）→ ポリシーや設定で抑止、あるいは無効化を検討
- 判断が難しい／影響が読めない→ Microsoft サポートで目的確認・影響評価
コミュニティの範囲では、svchost 配下の詳細解析や「この通信は○○です」と断定するところまで踏み込まないことが多いです。サービス名が特定できた時点でサポートケースにすると、調査のスタートラインが一段上がります。
特定後の対処：外向き通信を「止める」ための代表パターン
通信元が特定できたら、ようやく対処の選択肢が現実的になります。ここでは Windows Server 2016/2019 で遭遇しやすい“外向き通信の系統”と、抑止／内部化の考え方をまとめます（実際に該当するかは必ずプロセス特定の結果に基づいて判断してください）。
| 系統 | よく使うポート | 目的（例） | 止め方の方向性 | 止める際の注意 |
|---|---|---|---|---|
| 時刻同期（NTP） | UDP 123 | 時刻合わせ | 外部NTP→内部NTPへ固定 | ドメイン環境では階層構造（PDC等）も考慮 |
| 更新（OS/Defender 等） | TCP 80/443 | パッチ・定義・コンポーネント更新 | WSUS/内部ミラー/管理配信へ | 無効化はセキュリティリスク。ラボでも方針決めが必要 |
| 証明書失効確認（CRL/OCSP） | TCP 80/443 | 証明書が失効していないか検証 | 内部CA/内部配布点を整備、到達性確保 | 無効化はリスク増。アプリや TLS に影響することがある |
| 診断・テレメトリ | TCP 443 | 診断データ送信、改善目的 | GPO/設定で抑止 | エディションや設定可能範囲に差がある |
| 接続状態チェック等 | TCP 80/443 | インターネット接続の可否判定 | アクティブプローブ停止など | 一部機能の表示や自動判定に影響 |
例：外部 NTP（UDP/123）を内部 NTP に変更する
質問の追加情報として挙がりやすいのが時刻同期です。Windows が既定で外部 NTP に同期しに行くのが気になる場合、内部 NTP を参照するように変更できます。
w32tm /config /syncfromflags:manual /manualpeerlist:"<内部NTPのIP>"
w32tm /config /reliable:yes /update
w32tm /resyncラボ内で閉じたい場合は、NTP だけでなく DNS・更新・証明書配布点なども「内部に寄せる」発想が重要です。
更新系（Windows Update / Defender 定義更新）を外に出さない設計にする
TCP 80/443 の外向き通信で最も遭遇しやすいのが更新系です。単純にサービスを止めると、期待しない不具合や脆弱性リスクが積み上がります。ラボでも以下のいずれかに寄せるのが現実的です。
- WSUS 等で内部配信（外への到達は WSUS サーバーだけに限定しやすい）
- オフライン更新運用（定期的に更新媒体を持ち込み、対象セグメントでは外向きを許可しない）
- 更新関連の自動動作を抑止（ただし「抑止した結果どう運用するか」までセットで決める）
ここで重要なのは「更新を止める」ではなく「更新の出口を集約する」です。出口が集約できれば、ファイアウォールのポリシーも“IP いたちごっこ”になりにくくなります。
証明書失効確認（CRL/OCSP）を疑うべき場面
外向き TCP 80/443 が「一定間隔で」「様々な IP に」出る場合、証明書の失効確認（CRL/OCSP）やルート証明書関連の取得が絡むことがあります。たとえば次のようなタイミングで発生し得ます。
- TLS 通信を張るアプリが起動した
- 特定の署名付きファイルやスクリプトを実行した
- 証明書チェーンの検証が走った
この系統は「止める」よりも「内部で完結させる」が基本です。企業内 CA を使っているなら CRL 配布点が内部で到達できるか、外部証明書を使うなら必要な検証が外に出ない設計になっているかを確認します。
なお、失効確認そのものを無効化する設定は存在しますが、セキュリティ上の意味合いが大きく、安易に推奨しません。どうしても必要なら、対象範囲（特定アプリのみ等）と影響を切り分け、リスク受容の判断をした上で実施してください。
診断・テレメトリ系は「ポリシーで抑止」しやすい
診断データ送信などは、環境ポリシーにより抑止できることが多い領域です。ここでやりがちなのは「よく分からない IP を全部ブロック」ですが、診断系は宛先が変わりやすいため、結局ログが止まらないことがあります。
プロセス／サービスが特定できたなら、以下の流れで扱うのが実務的です。
- その機能が必要か（サーバー用途、ラボ用途、要件）を決める
- 必要なければ GPO / レジストリ / サービス設定で抑止する
- 必要なら、許可する出口・許可範囲を最小化する
「プロキシを入れたのに出ていく」を潰すチェックリスト
原因特定と並行して、プロキシ設定周りの“見落とし”も潰しておくと調査が早くなります。
| チェック項目 | 確認方法（例） | 期待値 | ズレていた場合の示唆 |
|---|---|---|---|
| WinHTTP プロキシの現在値 | netsh winhttp show proxy | 意図したプロキシが設定されている | 設定漏れ／別手順で上書きされている |
| WinINET（ユーザー）側のプロキシ | インターネットオプション等 | ユーザーアプリが使う設定が想定通り | ユーザーアプリが直結している可能性 |
| PAC/WPAD の影響 | 自動検出設定、DNS/AD の設定 | 意図しない自動検出が働いていない | 一部通信だけバイパスされる可能性 |
| 例外（バイパス）設定 | プロキシの除外設定 | 必要最小限の除外のみ | 除外が広すぎて直結になっている |
ただし、ここまで整えても「外向き通信が続く」ことはあり得ます。その場合はやはりプロセス／サービス特定が最重要です。
外向き通信を“止める”ためのネットワーク側アプローチ（補助策）
プロセス特定と設定変更が理想ですが、検証中に「とにかく外に出したくない」「ログの量を減らしたい」局面もあります。その場合の補助策を整理します。
| アプローチ | 狙い | メリット | デメリット |
|---|---|---|---|
| 出口をプロキシのみに固定（ネットワークで強制） | 直結の余地を消す | IP いたちごっこから脱却しやすい | プロキシ非対応通信は全滅する |
| Windows Defender Firewall の送信を原則拒否→必要通信だけ許可 | 最小権限化 | サーバー単体で制御できる | 設計/運用が難しく、業務影響が出やすい |
| 境界 FW で egress を集約（許可先を最小化） | 管理点を集中 | ルールの統制が取りやすい | DNS/FQDN 変動の扱いが課題 |
注意点として、これらは“通信試行そのものを止める”のではなく、外へ出ないようにするだけです。根治には、やはりプロセス特定→設定変更が必要になります。
どうしても正体が掴めない場合：Microsoft サポートへ持ち込む判断基準
コミュニティでは「パケットやログの詳細解析はサポート範囲外」とされることが多く、また OS 内部動作の目的確認はベンダー確認が必要になる場面があります。次の条件に当てはまるなら、早めに Microsoft サポート案件として切るほうが結果的に早いです。
- 発信元プロセスが掴めない（ログに出ない、再現性が低い）
- svchost.exe までは分かったが、サービスが多く特定できない／特定しても影響判断ができない
- 「止めてよいか」が要件上きわめて重要（監査・規制・分離ネットワーク）
- OS の既定動作か、バグ/誤設定か、第三者ソフトかの切り分けが必要
サポートへ渡す材料としては、次が揃っていると調査が加速します。
| 材料 | 最低限ほしい内容 | 目的 |
|---|---|---|
| ファイアウォールログ | 日時、宛先IP/ポート、許可/拒否 | 発生頻度・傾向の把握 |
| WFP 監査イベント or Sysmon | プロセス名/パス、PID、宛先 | 誰が出しているかの確定 |
| netsh trace 等のトレース | 再現時間帯の ETL | 内部動作の裏取り |
| 環境情報 | OS ビルド、役割、GPO、プロキシ/WSUS 有無 | 既知動作/既知問題の照合 |
まとめ：最短で「外向き通信の正体」と「止め方」に到達する流れ
最後に、今回のような「Windows Server 2016/2019 がプロキシ設定を入れても外部 Public IP に 80/443 を投げる」問題で、迷いにくい実務フローをまとめます。
| ステップ | やること | ゴール |
|---|---|---|
| 観測 | FWログで宛先/頻度/ポートを整理 | 「何が起きているか」を言語化 |
| 特定 | リソースモニター → netstat → WFP監査/Sysmon の順で発信元を掴む | プロセス名/PID（できれば実行パス）を確定 |
| 深掘り | svchost ならサービス名を特定（tasklist /svc 等） | 「どのサービスが」まで落とす |
| 対処 | 対象サービスの設定で内部化・抑止（NTP/WSUS/診断など） | 通信試行そのものを減らす |
| 判断 | 必要性・影響が不明ならサポートへ | 安全に「止めてよいか」を確定 |
IP ブロックだけで追いかけると、宛先が変わるたびにルールが増えて疲弊しがちです。まずは発信元（プロセス／サービス）を特定し、その上で設定・ポリシーで制御する――この順番が、最も遠回りに見えて最短です。
コメント