「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から実行できる。

# (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

{ 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

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

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は無罪」「拡張は無罪」「サーバは無罪」を実測で潰していくと、 残りが一意に決まる