# 「1台だけそのサイトが開けない」を30分で確定させる — IPv4専用サイト × IPv6回線 社内サイトや自社サーバが **特定の1台だけ `ERR_CONNECTION_TIMED_OUT` で開けない**とき、 Cookie 削除・キャッシュ削除・再起動をいくら試しても直らないことがある。 真因が **アプリ層ではなくIPプロトコル層（IPv4経路の不在）** にあるケースの、確定手順をまとめる。 この指示書は「サーバを疑う前にサーバ側の無罪を実測で証明し、次に端末側を読み取り専用コマンドだけで確定させる」流れを、 **リモート接続中・会議中の端末を切断せずに**実行できる形で書いてある。 --- ## 0. 症状の見分け方（これに当てはまるなら本手順） - 1台（または1回線）だけ開けない。他の人は同じサイトを問題なく開けている - エラーは `ERR_CONNECTION_TIMED_OUT`（`ERR_CONNECTION_REFUSED` でも `ERR_NAME_NOT_RESOLVED` でもない） - **Cookie / キャッシュ削除が効かない** - **シークレットウィンドウでも開けない**（＝拡張機能は無罪） - その端末で Google 系サービス（Meet, Gmail, YouTube）は普通に動いている ← **重要な手がかり** 最後の項目が決定的なヒントになる。大手サービスは IPv6 に対応しているので、 **端末の IPv4 経路が死んでいても普通に使える**。一方、中小規模の自社サーバは IPv4 専用であることが多く、 **そこだけが落ちる**。この非対称性が「サイトが落ちた」「ブラウザが壊れた」という誤診を生む。 --- ## 1. まずサーバ側の無罪を証明する（自分の端末から実測・所要2分） 人に何かを頼む前に、**手を動かせる範囲は全部先に潰す**。以下は自分のPCから実行できる。 ```bash # (a) サーバが生きているか curl -sS -o /dev/null -w "http=%{http_code} time=%{time_total}\n" --max-time 12 https://<対象ドメイン>/ # (b) IPv6 を持っているか（AAAA レコード） nslookup -type=AAAA <対象ドメイン> # または: dig AAAA <対象ドメイン> +short # (c) HTTP/3(QUIC) を広告しているか curl -sI --max-time 10 https://<対象ドメイン>/ | grep -i "alt-svc\|server" # (d) UA でブロックしていないか（相手端末のOSのUAを騙って叩く） curl -sS -o /dev/null -w "http=%{http_code} time=%{time_total}\n" --max-time 12 \ -A "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.0 Safari/605.1.15" \ https://<対象ドメイン>/ ``` 判定: | 結果 | 結論 | |---|---| | (a) が 200/301/302 を即返す | **サーバは稼働中**。全体障害ではない | | (b) に AAAA が**無い** | **サイトは IPv4 専用** → 本手順の本命シナリオ | | (c) に `alt-svc` が**無い** | QUIC/UDP443 起因を除外できる | | (d) が正常応答 | UA ブロック・IPブロックを除外できる | ここまでで「サーバ側の問題ではない」と**実測で**言えるようになる。 推測で「サーバは大丈夫だと思います」と言わないこと。ログや記憶は証拠にならない。 --- ## 2. 端末側を読み取り専用で確定させる（所要1分） 相手の端末で実行してもらう。**すべて読み取り専用**なので、リモートデスクトップ接続も オンライン会議も切れない。ここが重要で、`Wi-Fi off/on` や DHCP 取り直しを最初に打つと **相手を操作不能にして事態を悪化させる**。 ### macOS ```bash { echo "### v4addr"; ipconfig getifaddr en0; ipconfig getifaddr en1; echo "### v4route"; netstat -rn -f inet | head -6; echo "### pingv4"; ping -c 2 -t 5 8.8.8.8; echo "### globalip"; curl -s --max-time 8 https://ifconfig.me; echo; echo "### curl4"; curl -4 -sS -o /dev/null -w "v4=%{http_code}\n" --max-time 8 https://ifconfig.me; echo "### target"; curl -sS -o /dev/null -w "http=%{http_code} t=%{time_total}\n" --max-time 10 https://<対象ドメイン>/; echo "### tcp443"; nc -vz -w 5 <サーバIP> 443; echo "### proxy"; scutil --proxy; echo "### hosts"; grep -i <ドメインの一部> /etc/hosts; echo "### firewall"; /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate; } 2>&1 ``` ### Windows ```powershell ipconfig | Select-String "IPv4|IPv6|ゲートウェイ|Gateway" ping -n 2 8.8.8.8 curl.exe -s --max-time 8 https://ifconfig.me Test-NetConnection <サーバIP> -Port 443 netsh winhttp show proxy ``` ### Linux ```bash ip -4 addr show; ip -4 route; ping -c 2 -W 5 8.8.8.8 curl -s --max-time 8 https://ifconfig.me; curl -4 -s --max-time 8 https://ifconfig.me ``` --- ## 3. 出力の読み方（原因が一意に決まる） | 観測 | 意味 | |---|---| | **IPv4 アドレスが `172.20.10.x`、gw が `172.20.10.1`** | **iPhone のインターネット共有（テザリング）**。iOS が配る固定レンジなので即断できる | | IPv4 アドレスが `192.168.x` / `10.x` で gw も同網 | 通常のルータ配下。テザリングではない | | **IPv4 アドレスが空** | OS 側で IPv4 が無効化されている（macOS: システム設定 → ネットワーク → 詳細 → TCP/IP の「IPv4を構成」がオフ） | | **`ping 8.8.8.8` が 100% packet loss** | IPv4 の外部到達性が無い（ICMP 遮断の可能性も残るので次行と併読） | | **`curl ifconfig.me` が IPv6 アドレスを返す** | 外向き通信が IPv6 で出ている | | 上2つが同時に成立 | **IPv4 経路の不在が確定**。IPv4専用サイトだけ落ちる説明がつく | | `nc -vz ... 443` が `Operation timed out` | ブラウザ非依存。アプリ層（Cookie・拡張・プロファイル）は全部無罪 | | `scutil --proxy` に `HTTPEnable: 1` が無い | プロキシ無罪 | | `/etc/hosts` に該当行なし | hosts の汚染なし | | ファイアウォールが `disabled` | ローカルFW無罪 | **IPv4 経路の不在が確定した時点で、犯人はブラウザでもサーバでもなく回線**である。 --- ## 4. 直し方 優先順: 1. **回線を変える** — Wi-Fi をテザリングから通常の回線（オフィス/自宅のルータ）に切り替える。**1操作で終わる本命** 2. **テザリングのまま使う必要がある場合（iPhone）** — iPhone の **設定 → インターネット共有 →「互換性を最大にする」をオン**。 IPv4 が有効になり IPv4専用サイトへ到達できるようになる（代償: 2.4GHz 固定になり速度が落ちる） 3. **OS 側で IPv4 が無効だった場合** — ネットワーク設定の「IPv4を構成」を DHCP に戻す 4. **恒久対策（サーバ運営側）** — 対象サーバに **AAAA レコードを付けて IPv6 対応**させる。 これをやれば IPv6 シングルスタック回線からも到達できるようになり、この障害は二度と起きない ### 実行タイミングの注意 相手の端末をリモート操作している / オンライン会議中なら、 **1と3は接続が一瞬切れる**。切れてよいタイミングかを先に確認してから実行する。 `networksetup -setairportpower en0 off` のようなコマンドを診断段階で混ぜてはいけない。 --- ## 5. 復旧を待たせない（並行してやるべきこと） 原因調査と**同時に**、相手が本来やりたかったこと（そのサイトの情報を読む）を別経路で満たす。 サイトの内容が別の場所（ドキュメント基盤、エクスポート済みデータ、ローカルの索引）に 同期されているなら、そこから中身を出して渡せば、相手は復旧を待たずに仕事を続けられる。 **障害対応の成果物は「原因の特定」ではなく「相手が仕事に戻れたか」である。** --- ## 6. この手順が守っている原則 - **人に頼む前に、自分の端末から測れるものは全部測る**（サーバ側の無罪証明は依頼ゼロでできる） - **人に残すのは「その端末の中でしか読めない情報」だけ**。ネットワークインターフェースの状態は代理取得できない - **診断は読み取り専用に限定する**。書き込み系（設定変更・電源操作）を混ぜると相手を操作不能にする - **1回のコピペで全項目が出る**ようにまとめる。往復のたびに人の手を止めない - **除外した原因を明示する**。「Cookieは無罪」「拡張は無罪」「サーバは無罪」を実測で潰していくと、 残りが一意に決まる ---