Windows 7だけWebサイトにアクセスできない原因と対処法｜IPv4変更・IPv6対応サーバー移行後のタイムアウトを切り分ける

Webサーバー移行で「IPv6対応＋IPv4アドレス帯変更」が行われた直後から、同一LAN内なのに“特定のWindows 7 PCだけ”複数サイトへブラウザがタイムアウトしてアクセスできない――こうした現象は、DNSや経路の断ではなく、PC側の通信スタック／プロキシ／フィルタ／MTU／IPv6優先度など“HTTP/HTTPSの手前”で詰まっていることが多いです。現場で迷わない切り分け手順を、実務目線で整理します。

現象の整理：サーバー移行（IPv4変更＋IPv6対応）後に「特定のWindows 7だけ」タイムアウトする

今回の状況は、典型的な「サーバー側の構成変更が引き金になったが、症状はクライアント固有に出る」パターンです。Webプロバイダが新アーキテクチャへ移行し、IPv6対応と引き換えにIPv4アドレス帯が変更（例：37.9.175.131〜133）された直後から、複数ドメインでタイムアウトが発生しています。

• 同じネットワーク内の他端末（Windows XP / Mac / スマホなど）は問題なし
• 同じLAN内でも、別のWindows 7端末は正常
• 問題のWindows 7だけ、複数サイトへブラウザがタイムアウト
• ブラウザ変更、キャッシュ削除、セキュリティソフト停止、Firewall停止、DNSフラッシュ、ルータ交換、DNSをGoogle/OpenDNSへ変更…などの一般的対処は効果なし
• nslookupで名前解決できる／tracertで新IP（例：37.9.175.133）まで到達できる

この時点で「DNS不良」「ルーティングが完全に死んでいる」は優先度が下がります。一方で、ブラウザが使うHTTP/HTTPS（TCP 80/443）のどこかで詰まっている可能性が上がります。

最初にやるべき切り分け：IP直打ちで“TCP/HTTPSに到達できているか”を見る

スレッドの結論でもまず推奨されているのがIPアドレス直打ち（例：37.9.175.133）でアクセスできるかの確認です。ここで「名前解決が原因なのか」「TCP/HTTPSが原因なのか」を一気に切り分けられます。

テスト	狙い	結果の読み方	次にやること
ブラウザでIP直打ち（HTTP） 例：http://37.9.175.133/	DNSを介さずHTTP接続できるか	表示できるならDNS/名前解決系が怪しい。タイムアウトならTCP/フィルタ/MTUなどが怪しい	hosts／プロキシ／Winsock／MTUへ
ブラウザでIP直打ち（HTTPS） 例：https://37.9.175.133/	443/TLSの到達性を見る	証明書警告が出ても“接続自体”できればネットワーク層は通っている。完全タイムアウトは要注意	WiresharkでSYN〜TLSまで追う
TCPポート疎通（代替） 例：telnet/pspingで80/443	ブラウザ要因を排除してTCP接続だけ確認	SYNが返らない／RSTが返るなどで方向性が決まる	セキュリティ製品／FW／経路MTUを疑う

注意（HTTPSのIP直打ちは万能ではありません）
移行後のWebサーバーは、1台のIP上に複数サイトを載せる「バーチャルホスト」が一般的です。HTTPSの場合はSNI（接続先ホスト名の提示）が必要になり、IP直打ちだと期待したサイトが表示されない・証明書が一致しないことがあります。とはいえ、ここで見たいのは「サイトが正しく出るか」ではなく、TCP 443が成立しTLSが始まるかなので、切り分けとしては十分価値があります。

Windows 7で“ブラウザ以外”のTCP疎通を見たい場合、手元にツールがあるなら以下が早いです。

• telnet（機能が無効なら「プログラムと機能」→「Windowsの機能の有効化または無効化」で有効化）
• Sysinternalsのpsping（TCP 80/443の接続テストに強い）

例：telnetで80番を確認（接続できれば真っ黒画面になる）
telnet 37.9.175.133 80

「nslookupはOK」「tracertも届く」のに、ブラウザだけタイムアウトする理由

ここでいちばん重要なのは、nslookupとtracertが“見ている世界”は、ブラウザのHTTP/HTTPSと一致しないという点です。

コマンド／機能	主に確認しているもの	落とし穴
nslookup	DNSサーバーに問い合わせた結果	hostsファイルは参照しないため、PC内で名前→IPが固定されていても気づきにくい
tracert	経路上のルータ応答（主にICMP/TTL）	TCP 80/443が通る保証はない。FWやフィルタは“HTTP/HTTPSだけ”落とすことがある
ブラウザ（HTTP/HTTPS）	TCP 3-way handshake→TLS→HTTP	プロキシ、LSP/Winsock、MTUブラックホール、TLS要件、IPv6優先など“PC固有”が影響

つまり、nslookupとtracertが正常でも、ブラウザがタイムアウトすることは珍しくありません。特に「移行でIPが変わった」「IPv6が有効になった」というイベントがあると、これまで表に出なかったクライアント側の歪みが露出しやすくなります。

原因になりやすい順に潰す：特定のWindows 7 PCだけアクセスできない時の実務チェック

hostsファイルに“旧IP固定”が残っていないか確認する（最優先）

スレの状況（DNSは引けるがブラウザが失敗）で、最初に疑うべき代表がhostsファイルです。nslookupはhostsを見ないため、hostsに古いIPが書かれていると次のようなズレが起きます。

• nslookup：DNSから新IPを返す（正常に見える）
• ブラウザ：hostsの旧IPへ接続し続け、タイムアウトする

確認箇所は以下です（管理者権限が必要な場合があります）。

• C:\Windows\System32\drivers\etc\hosts

対象ドメイン（例：example.com）が次のように書かれていないかチェックします。

例：移行前のIPを固定しているケース（削除またはコメントアウト）
37.9.175.120  example.com
37.9.175.120  www.example.com

修正後は以下も実施します。

ipconfig /flushdns

同時に、ブラウザやアプリが参照するキャッシュの影響を減らすため、PC再起動まで行うと確実です。

プロキシ設定／WPAD／WinHTTPプロキシの“二重管理”を確認する

「インターネットオプションのプロキシはオフにしたのに改善しない」という時、見落としがちなのがWPAD（自動プロキシ検出）と、Windows内部のWinHTTPプロキシです。アプリや更新系コンポーネントがWinHTTPを使う場合、IE設定とは別にプロキシが残っていることがあります。

確認ポイントはこの3つです。

• コントロールパネル → インターネットオプション → 接続 → LANの設定
  • 「設定を自動的に検出する」
  • 「自動構成スクリプトを使用する」
  • 「LANにプロキシ サーバーを使用する」
• WPAD/DHCP/DNSによる自動設定（社内ネットワークでよくある）
• WinHTTPプロキシ

WinHTTPプロキシの確認
netsh winhttp show proxy

WinHTTPプロキシのリセット（環境により影響があるため“切り分け用”として実施）
netsh winhttp reset proxy

また、セキュリティ製品の「Web保護」「HTTPSスキャン」「フィルタリング」は、画面上で停止してもドライバやLSPが残って通信を変えることがあります。プロキシを疑う場合は、一時的にセーフモード（ネットワークあり）で再現するか、切り分けとしてアンインストールまで含めて検討すると前進しやすいです（業務PCでは運用ルールに従ってください）。

Windows 7のネットワークスタック（Winsock/LSP）をリセットする

「同じLAN内でこのPCだけ」という条件で、現場で当たりが多いのがWinsock（LSP含む）の破損やねじれです。VPNクライアント、Webフィルタ、古いセキュリティソフトなどが原因で、特定の宛先・特定のプロトコルだけ失敗することがあります。

代表的なリセット手順は次の通りです（管理者権限で実行し、最後に再起動）。

DNSキャッシュの削除
ipconfig /flushdns

Winsockのリセット（LSP含む）
netsh winsock reset

TCP/IPスタックのリセット
netsh int ip reset

この操作で改善するなら、根本原因は「通信を挟み込む何か（LSP/フィルタ/ドライバ）」である可能性が高いです。改善しない場合でも、以降の切り分けが楽になります。

IPv6が絡む“片方向トラブル”を切り分ける（移行後に増える）

サーバーがIPv6対応すると、DNSにAAAAレコードが追加されることがあります。クライアント側がIPv6を優先し、そのPCだけIPv6経路が壊れていると、ブラウザはIPv6で接続しようとして待ち、タイムアウトのように見えることがあります。

同一LAN内で他端末が正常でも、問題PCだけ以下のような要因でIPv6が不安定なケースがあります。

• トンネリング（Teredo / 6to4 / ISATAP）の状態が崩れている
• NICドライバやセキュリティ製品がIPv6だけを阻害している
• レジストリやポリシーでIPv6優先度が変わっている

まずは現状確認です。

ipconfig /all

切り分けとして“短時間だけ”IPv6を無効化して改善するかを見るのは有効です（恒久対応にする前に必ず影響評価）。

• ネットワークアダプタのプロパティ → 「インターネット プロトコル バージョン 6 (TCP/IPv6)」のチェックを外す（切り分け）

トンネリング要素を疑う場合は、状態確認と無効化も手がかりになります。

IPv6関連の状態確認（環境により出力は異なる）
netsh interface ipv6 show interfaces

Teredoを無効化（切り分け）
netsh interface teredo set state disabled

6to4を無効化（切り分け）
netsh interface ipv6 6to4 set state disabled

ISATAPを無効化（切り分け）
netsh interface ipv6 isatap set state disabled

もしIPv6を切ると改善する場合、次の一手は「ルータ側のIPv6設定（RA/DHCPv6/プレフィックス配布）」と「問題PCのIPv6スタック／ドライバ／フィルタ」を掘ることになります。逆にIPv6を切っても改善しないなら、原因は別（MTU、プロキシ、TLS、フィルタ等）の可能性が高まります。

MTUブラックホール（経路MTU不整合）を疑う：特定サイトだけタイムアウトの典型

「tracertは通るのに、特定サイトだけタイムアウト」「移行後に経路が変わった」「VPNやPPPoEが絡む」――この条件で頻出なのがMTUブラックホールです。パケットが大きいと途中で落ち、断片化もされず、結果としてTCPが進まずタイムアウトします。

目安として、一般的なMTUの例は以下です。

回線／環境	よくあるMTU	備考
Ethernet（一般的なLAN）	1500	標準的。ここからVPNなどで実効MTUが下がることがある
PPPoE	1492	家庭用回線でよくある。さらに上位で制限がある場合も
VPN（種類による）	1400前後〜	カプセル化で小さくなることが多い

Windows 7では、DF（フラグメント禁止）を付けたpingで「どのサイズまで通るか」を試して目安を掴みます（相手がICMPを落としていると判定しづらい点に注意）。

例：1500(イーサ)からIP/ICMPヘッダ分を引いたサイズで試す（まず1472）
ping 37.9.175.133 -f -l 1472

通らなければサイズを下げて再試行（例：1464、1452…）

もし明らかに小さくしないと通らないなら、PCまたは経路上のどこかでMTU不整合が起きています。恒久対策としては、NICや回線装置側の設定と整合させたMTUへ調整します（名称は環境により異なります）。

例：インターフェース名を確認
netsh interface ipv4 show subinterfaces

例：MTUを設定（値は環境に合わせて検討）
netsh interface ipv4 set subinterface "Local Area Connection" mtu=1492 store=persistent

MTUは影響範囲が広い設定です。闇雲に下げるのではなく、「問題サイトへの通信が進むようになるか」という結果とセットで判断し、必要ならルータやVPN装置側のMSSクランプ（TCP MSS調整）も含めて検討します。

HTTPS要因（TLS/暗号設定/更新状況）を確認する：Windows 7の“個体差”が出やすい

サーバー移行でTLS要件が上がると、古い環境は突然つながらなくなることがあります。今回「別のWindows 7は動く」ため優先度はやや下がりますが、問題PCだけ更新不足や設定差があると十分起こりえます。

チェックポイントは次の通りです。

• Windows Updateが止まっていないか（長期間未適用のPCは差が出る）
• インターネットオプション → 詳細設定でTLS 1.2が無効になっていないか（IE系コンポーネントを使うアプリで影響）
• PCの日時がズレていないか（証明書検証で失敗し、挙動が不安定に見えることがある）
• ルート証明書ストアの更新が極端に古くないか

ポイントは「TLSエラーは“エラー表示”が出る」とは限らないことです。ブラウザやセキュリティ製品の挟み込み方によっては、失敗がタイムアウトっぽく見えることもあります。通信キャプチャでTLSハンドシェイクの途中で止まっているなら、この線が濃くなります。

NICドライバ／オフロード機能／省電力設定：なぜか“そのPCだけ”を作る定番

地味ですが、最後まで残りやすいのがNICドライバやオフロード機能の相性です。サーバー側が新アーキテクチャへ移行し、経路や応答特性が変わったことで、古いNICドライバの癖が表面化することがあります。

• ネットワークアダプタのドライバ更新（メーカー／チップベンダーの安定版）
• 省電力設定の見直し（「電力の節約のために…」を外す）
• 切り分けとしてオフロード機能（Large Send Offloadなど）を無効化して再現性を見る

オフロードは性能に寄与しますが、特定の経路や装置と相性が出ると「特定サイトだけ不安定」になり得ます。手順は環境依存なので、変更する場合は現状値を記録して戻せる状態で行い、改善が確認できたら恒久対応（ドライバ更新・設定整合）に寄せるのが安全です。

セキュリティ製品／フィルタドライバ：停止しても“通信経路に残る”ことがある

Web保護・HTTPS検査・広告ブロック・フィルタリングなどは、通信経路にドライバを挿し込むタイプが多く、GUI上の停止だけでは完全に外れません。今回「セキュリティソフト停止でも改善しない」とのことですが、切り分けとしての“停止”と、通信経路から外れることは別です。

現実的な切り分け案は以下です（運用ルール・許可に従ってください）。

• セーフモード（ネットワークあり）で再現するか確認する
• 同等条件の“クリーンなWindows 7”や別ユーザーで再現比較する
• 一時的にアンインストール（必要ならベンダーのクリーンアップツールも）で通信経路から外す

ここで改善するなら、原因はセキュリティ製品やフィルタの可能性が高く、ベンダーに「移行後のIP帯（例：37.9.175.131〜133）への接続でタイムアウトする」ことと「通信キャプチャ結果」を添えて問い合わせるのが近道です。

通信キャプチャで原因特定：タイムアウトの“どこで止まるか”を一発で見抜く

スレッドの流れでも触れられている通り、最終的に確実なのはネットワークキャプチャ等で通信をトレースして分析することです。フォーラムではログ収集・解析に制約があるため、受理回答としては「有償サポート（1対1の技術支援）へ依頼」が推奨される形になっています。

社内で対応する場合は、次の方針が実務的です。

キャプチャは“問題PC”と“正常PC”の2台で同じ条件を取る

• 同じLAN、同じ時間帯
• 同じURL、同じDNS解決結果（可能ならA/AAAAをメモ）
• 問題PCと正常PCで同時にアクセスし、差分を見る

Wireshark等で見るべきポイントは大きく3段階です。

• TCP 3-way handshake（SYN → SYN/ACK → ACK）が成立しているか
• HTTPSならTLSハンドシェイクが進むか（ClientHello→ServerHello…）
• HTTPリクエスト/レスポンスが返っているか（GET/200/301など）

キャプチャの典型パターンと疑うべき原因

キャプチャで見える現象	起きていること	疑うべき原因	次の打ち手
SYNを送っているがSYN/ACKが返らず再送を繰り返す	TCP接続が張れない（到達性/フィルタ）	FW/フィルタ、経路上の遮断、誤った宛先IP（hosts等）	hosts確認、セキュリティ/FWの“完全除外”、別回線テスト
SYN/ACKは返るが、その後RSTが返る／すぐ切れる	接続は成立するが即座に切断	中間装置の制御、プロキシ、セキュリティ製品の介入	プロキシ/WPAD、LSP、製品ログ確認
TCPは成立するがTLSの途中で止まる（ClientHello後に進まない等）	TLS要件不一致または中間者問題	TLS1.2/暗号、証明書、HTTPSスキャン、古い更新状態	更新適用、TLS設定、HTTPSスキャン無効化（切り分け）
小さい通信は返るが、大きいレスポンスで止まる／再送が多い	MTUブラックホールの疑い	MTU/MSS不整合、VPN/PPPoE、経路変更	ping -f -l、MTU/MSS調整、装置側設定見直し
IPv6宛（AAAA）で試して失敗、IPv4（A）なら成功	IPv6経路またはPC側IPv6スタックが不安定	IPv6設定、トンネリング、NIC/フィルタのIPv6相性	IPv6一時無効化、Teredo/6to4無効化、ルータIPv6確認

この“どこで止まっているか”が分かるだけで、原因候補が一気に絞れます。逆に、キャプチャ無しで当てに行くと、同じ作業を延々と繰り返しがちです。

再現条件を作ると解決が早い：現場で効く比較テストのコツ

「特定のWindows 7だけ」という問題は、比較で勝ちやすいです。次のテストは、短時間で状況を動かせます。

問題PCを“別ネットワーク”に出してみる（LAN起因かPC起因か）

• 可能ならスマホのテザリングなど、別の回線で同じドメインへアクセス
• 別回線で直る → 社内LAN/ゲートウェイ/フィルタ/IPv6配布が怪しい
• 別回線でも同じ症状 → PC固有（Winsock、プロキシ、製品、更新差、NIC）を優先

同じドメインでも“IPを固定して”比較する（DNS変動の影響を排除）

DNSが複数IPを返す（ラウンドロビン、CDN、移行中の混在）場合、アクセス先が揺れて切り分けが難しくなります。切り分けでは「同じIPに向けて」テストすると再現性が上がります。

• DNS応答で返ったA/AAAAをメモして、IP直打ち（HTTP）やTCP疎通で比較
• 通信キャプチャでは、対象IPをフィルタにして差分を見る

ブラウザ差が出るなら“OS設定依存”を疑う

IEだけ、Chromeだけ、といった差が出る場合は、以下を疑います。

• IEのプロキシ/TLS設定
• Windows証明書ストア（ルート証明書）
• セキュリティ製品のブラウザ拡張やHTTPS検査

ただし今回のように「ブラウザ変更済みでも改善しない」なら、ブラウザより下（OS/ドライバ/フィルタ）に寄っている可能性が高いです。

フォーラムの結論：IP直打ち→ダメなら通信トレース→解析が難しければ有償支援へ

スレッドの受理回答としての流れは、実務でも理にかなっています。

• IPアドレス直打ちでアクセス可否を確認し、DNS起因かどうかをまず切り分ける
• それでもダメなら、原因特定にはネットワークキャプチャ等で通信トレースして分析が必要
• ただしフォーラムではログ収集・詳細解析に制約があるため、Microsoftの有償サポート（1対1の技術支援）に依頼するのが推奨、という形で受理回答になっている

なお、現代の運用観点では、Windows 7は既にサポートが終了しているため、公式の支援窓口が当時と同じ形で提供されないケースがあります。その場合でも、やるべきことは変わりません。キャプチャで止まっている箇所を特定し、該当領域（ネットワーク機器ベンダー／セキュリティ製品ベンダー／社内NW担当／外部のネットワーク専門会社）へエスカレーションするのが現実的です。根本的なセキュリティリスクを考えると、可能であればOS更改も検討対象になります。

現場向けチェックリスト：最短で結論に近づく手順

最後に、今回のような「サーバー移行後、特定のWindows 7だけ複数サイトにタイムアウトでアクセスできない」問題で、実務的に効く順番をまとめます。

手順	やること	確認ポイント	改善したら
切り分け1	IP直打ち（HTTP/HTTPS）／TCP疎通確認	DNSを介さずに80/443へ到達するか	DNS/hostsか、TCP/HTTPS層か方向性が決まる
切り分け2	hostsファイル確認	対象ドメインが旧IPで固定されていないか	旧記述を削除→flushdns→再起動
切り分け3	プロキシ/WPAD/WinHTTPプロキシ確認	自動構成・隠れプロキシが残っていないか	設定整合・不要設定の撤去
切り分け4	Winsock/TCP/IPリセット	LSPやスタック破損の復旧	改善するなら“挟み込み系”を重点調査
切り分け5	IPv6一時無効化・トンネル無効化	IPv6優先で詰まっていないか	IPv6経路/配布/ドライバ/フィルタを見直す
切り分け6	MTU検証（ping -f -l）	大きい通信が落ちていないか	MTU/MSSを設計値に整合
確定	Wireshark等で通信キャプチャ	TCP/TLS/HTTPのどこで止まるか	該当領域のベンダー／担当へ根拠付きで依頼

「同一LANで1台だけ」「複数ドメインでタイムアウト」「nslookupとtracertは正常」という条件は、闇雲に設定をいじるほど遠回りになりがちです。IP直打ちで方向を決め、hosts・プロキシ・Winsock・IPv6・MTUを上から順に潰し、それでも残るならキャプチャで“止まっている場所”を確定させる――この流れが、最も再現性が高い解決ルートです。