はじめに
在宅勤務中、自宅 PC から会社の VPN に接続したところ、 以下のように Chrome 系のブラウザだけが通信できない という非常に不可解な現象が発生しました。
Firefox → 正常表示
curl → 通信可能
SSH（VPN 内部 IP）→ 通信可能
Chrome → ERR_NETWORK_ACCESS_DENIED
Chrome Canary → 同じく失敗
ネットワークとしては正常なのに、Chrome だけが VPN 上で拒否。 再インストールしても改善せず、原因特定に苦労するタイプの障害でした。
本記事では「実際の調査プロセス」「原因」「解決方法」に加え、 同じ症状を引き起こし得る他の要因もまとめた “完全版” をお届けします。
結論（TL;DR）
原因
VPN 接続が Windows に Public ネットワーク扱い と誤判定され、 Chromium 系ブラウザだけが OS のセキュリティ制限を受けていた。
Firefox や curl はこの制限を受けないため正常だった。
解決
PowerShell（管理者）で VPN のネットワークカテゴリを Private に変更：
Set-NetConnectionProfile -InterfaceAlias "gracetory" -NetworkCategory Private
これだけで Chrome・Chrome Canary が即復活した。
図解①：今回発生した “不可解な通信状態”
┌─────────────────────┐ VPN接続 ┌───────────────────┐ │ 自宅 PC（Windows） │────────────▶│ 会社ネットワーク │ └─────────────────────┘ └───────────────────┘
通信テスト結果：
Firefox ────────── OK curl ────────── OK SSH ────────── OK Chrome ────────── NG（ERR_NETWORK_ACCESS_DENIED） Chrome Canary ───────── NG
図解②：Windows のネットワークプロファイル
Windows は各ネットワークを次のように分類します：
┌───────────────────────────────────────────────────┐ │ Windows のネットワーク分類 │ ├────────────────┬──────────────────────────────────┤ │ Private（信頼） │ 家庭LAN / 社内LAN など │ │ Public（非信頼）│ カフェWi-Fi / 未識別ネットワーク │ └────────────────┴──────────────────────────────────┘
問題発生時、VPN（gracetory）の状態は Public に誤判定されていました。
図解③：Public 扱いだと “Chrome 系だけ” 止まる理由
┌────────────────┐
│ Firefox / curl │ ← Public でも制限を受けない
└───────▲────────┘
│
│ 許可
│
┌───────────────┐ ┌───────────▼───────────────┐
│ ネットワーク層 │────▶│ Chromium アプリ │
│ （VPN / LAN） │ │（Public で強い制限を受ける）│
└───────────────┘ └───────────▲───────────────┘
│
│ Public ネットワークに対する
│ SmartScreen や Isolation の制限
│
▼
┌───────────────┐
│ Chrome / Edge │
│ Chrome Canary │
└───────────────┘
Chromium 系ブラウザのみが OS の “ネットワーク保護層” の影響を受けます。
調査で判明した決定的なポイント
PowerShell で確認：
Get-NetConnectionProfile
結果：
Name : gracetory NetworkCategory : Public ← ここが問題
VPN が Public → Chrome 系ブラウザが通信拒否 という構図が見えてきました。
解決方法
ネットワークカテゴリを Private に変更：
Set-NetConnectionProfile -InterfaceAlias "gracetory" -NetworkCategory Private
Chrome を再起動すると 即正常化。
なぜ “突然” Public に変わったのか？
以下が現実的な原因です（実例あり）。
1. Windows Update による VPN スタック再構成（最有力）
Windows Update → VPNアダプタの再生成
→ プロファイルが初期化されPublic 化
「昨日まで正常、今日から突然不可」という現象に完全一致。
2. VPN サーバ側の識別情報（NLA）が変化
Windows がネットワーク識別に使う情報が変わると、安全のため Public に格下げされることがあります。
3. Windows 11 の “未識別ネットワーク” バグ
VPN 接続直後に一瞬でも未識別 Network と誤判定するとそのままPublicに固定されてしまう現象がある。
4. LAN 側も Public のため整合性で統一された
LAN：Public
VPN：Private
→ Windows「両方 Public に揃えるか…」
複数 NIC の存在が原因になることもある。
再発防止策
✔ VPN は常に Private に固定
Set-NetConnectionProfile -InterfaceAlias "gracetory" -NetworkCategory Private
✔ LAN 側も Private に変更して整合性を取る
Set-NetConnectionProfile -InterfaceAlias "イーサネット" -NetworkCategory Private
✔ 未識別ネットワークを Private 扱いにする（強力な恒久対策） secpol.msc
→ ネットワーク一覧マネージャー
→ 未識別ネットワーク → Private
補足
「今回の原因ではなかったが、同じ症状を起こしうる要因一覧」
調査では以下の項目も確認しました。
今回は無関係でしたが、一般的にはよく原因になるため共有します。
1. Chrome の Secure DNS
VPN と DNS over HTTPS の相性が悪い場合、Chrome だけ DNS 解決に失敗することがあります。
2. WPAD（自動プロキシ検出）
誤ったプロキシ設定を拾うと、Chrome だけアクセス拒否されるケースがある。
3. Windows Firewall のパブリック制御
Chrome の「パブリックアクセス許可」が OFF だと、VPN 接続時だけ通信拒否になることがある。
4. SmartScreen / Reputation-based protection
Chromium 系だけ “未知のネットワークへの通信” を制限されることがある。
5. Controlled Folder Access
Chrome のネットワークサービスプロセスを誤って遮断する場合がある。
6. IPv6 の優先度問題
Chrome は IPv6 を積極的に使うため、VPN 上で IPv6 が不完全だと Chrome 系だけ失敗する例がある。
7. Chrome 内部キャッシュ（HSTS / ソケットプール）
Chrome の内部状態が破損している場合、Chrome だけ異常な挙動を見せることがある。
8. WinHTTP プロキシ設定の残骸
企業 PC の残設定などで WinHTTP が不正なプロキシを参照しているとChrome だけ通信できなくなることがある。
まとめ
原因：VPN が Public 判定 → Chromium 系のみ OS が通信制限
解決：NetworkCategory を Private に変更
再発防止：LAN/VPN の Private 統一 + 未識別ネットワークの Private 化
同じ症状を起こしうる要因も多数存在するため、診断時は Chrome だけを疑わず、OS の判定層を確認することが重要
本記事が同じ障害に悩むエンジニアの助けになれば幸いです。
最後に
この記事はチャッピー(流行語？)に書いてもらいました。実際にこのトラブルに遭遇し、ChatGPTに丸投げで解決を図りました。
そして、最後にやり取りをまとめてブログ記事にしてもらいました。
よくわからない図解を挟んでくる所がなかなか興味深い。
