MacでHTTPS接続エラーが頻発 ── 原因はまさかの「電源」だった
突然、Webサイトにアクセスできなくなった
ある日、MacのブラウザでWebサービスにアクセスしようとしたところ、「接続はプライベートではありません」「この接続ではプライバシーが保護されません」という警告が表示され、ページが開けなくなった。
SafariでもChromeでも同様のエラー。しかし、スマホからは問題なくアクセスできる。
「Macの設定がおかしいのか？」と最初は思ったが、調べていくうちに意外な原因にたどり着いた。
証明書を確認してみると……
ターミナルから証明書情報を確認したところ、アクセス先のサーバーではなく、自宅のルーターが発行した自己署名証明書が返されていた。
つまり、ブラウザが正規のサーバーと通信しているつもりで、実際にはルーターが通信を横取りして自前の証明書を返していたのだ。
DNS解決は正常で、IPアドレスも正しい。にもかかわらず、TLS通信の段階でルーターが割り込んでいる状態だった。
切り分けの過程
Claudeと一緒に以下の手順で切り分けを行った。
nslookup でDNS解決を確認 → 正常（正しいIPが返る）
openssl s_client でTLS証明書を確認 → 異常（ルーターの証明書が返される）
traceroute で経路確認 → ルーターで止まる
IPv6での接続を試行 → 同様にインターセプトされる
ルーター管理画面のパスワードが不明だったため、VPNトンネル（Cloudflare WARP）でバイパスする方針に切り替えたが、そもそもWARPの登録通信自体もルーターにブロックされてしまった。
真の原因
ふと気づいてONU（光回線終端装置）を見ると、電源が落ちていた。
ルーターはONUの先にあるインターネット回線に接続して初めて正常動作する。ONUの電源が切れていたことで、ルーターは「インターネット未接続モード」に移行し、すべてのHTTPSリクエストに対して自身の管理画面用証明書を返すキャプティブポータル的な動作をしていたのだ。
ONUの電源を入れ直したところ、即座に正常な証明書が返るようになり、すべてのWebサービスに問題なくアクセスできるようになった。
学び
HTTPS証明書エラーが出たら、まずネットワーク機器の物理的な状態を確認する。電源、LANケーブルの接続、ランプの状態など、基本的なところから。
ルーターの「インターネット未接続時の挙動」は機種によって異なる。今回のように全HTTPS通信をインターセプトするタイプは、原因特定が難しい。
ソフトウェア的な診断（nslookup、openssl s_client、traceroute）を組み合わせることで、問題の層（DNS／TLS／ルーティング）を特定できる。
スマホで問題ないのにPCで問題がある場合、接続経路の違い（モバイル回線 vs Wi-Fi）を疑う。
AIとの対話による切り分けは、ネットワークトラブルシューティングとの相性が良い。コマンドの提示→実行→結果の解釈→次の手、というサイクルが効率的に回る。
おまけ
トラブルシューティングの過程でインストールしたCloudflare WARPは、結果的に今回は不要だったが、カフェや空港のフリーWi-Fiなど不安定なネットワーク環境での通信保護に使えるため、そのまま残すことにした。無料で使え、メニューバーからワンクリックでON/OFFできるので、お守り代わりに入れておいて損はないかな。
