Claude Code で頻発する「API Error: Connection refused」の原因調査と hosts 回避（.10 → .11）

開発claude-code-tools

朝 8 時 37 分、セッションを開いて最初に打ったのは、エラーメッセージの貼り付けだった。 「API Error: Connection refused — a firewall or proxy may be blocking it (ConnectionRefused)」。 Claude Code でこのところ頻発している。 ファイアウォールにもプロキシにも心当たりはない。 そのまま「全部調べて、何が原因か」と投げた。

まずは PC の中、定番の容疑者から

Connection refused は、サーバー側の拒否ではなく、接続先かプロキシが TCP レベルで拒んでいるときのエラーだという。 そこで定番の容疑者を順に当たらせた。 死んだローカルプロキシを指したままのプロキシ設定、hosts や DNS の汚染、セキュリティソフトとファイアウォールの遮断だ。 このどれかだろうと思っていた。

全部白だった。

代わりに浮かび上がったのは、PC の外の構図だった。 Anthropic の全サービスは単一の anycast IP 160.79.104.10 に集約されている。 そしてこの IP のポート 443 宛の「新規 TCP 接続」だけが、10〜30分の波で断続的に落とされていた。 遮断が起きているのは PC 側ではなくその先で、自宅ルーターの NAT/SPI か、回線事業者の網か、Anthropic 東京エッジの防御機構か、どれなのかまでは絞り切れない。 ここまでの調査は issue ファイルに記録させた。

Codex で Windows と Mac を突き合わせる

ここから Codex 側で Windows と Mac の環境を突き合わせ、Windows の設定を変えた後の挙動まで検証した。 この追加検証で結論を二層構造に更新した。 一層目は Anthropic の IPv4 経路の間欠障害、二層目は VirtualBox のフィルターによる IPv6 フォールバックの阻害だ。 IPv4 が落ちたら IPv6 へ逃げればいい、というフォールバックの退路を、自分で入れた仮想化ソフトのフィルターが塞いでいた。

修正後の状態を Windows 実機で裏取りする

結論は出た。 それでも、Windows 実機のセッションからも修正後の状態を裏取りさせた（09:27〜09:32 JST）。 計測はバックグラウンドで回した。 途中で「どうですか、調子は」と聞くと、「思わしくない方向が濃厚」と返ってきた。 09:31 時点の IPv6 デフォルトルート（::/0）の残り寿命は 47:44 だった。 計測は、最後の curl -6 が失敗する exit 28 で終わった（想定どおりの失敗コード）。 修正したはずの Windows 側の IPv6 復旧は、維持できていなかった。

そして計測データは、設定変更ではなく「抜き差し（リンクアップ）こそが回復の直接トリガーだった」ことを示していた。 直したつもりの設定は、直接は効いていなかったらしい。

hosts の .10 → .11 回避を手順書にして GitHub へ

遮断箇所がどこかは、まだ絞り切れていない。 それでも回避はできる。 hosts で接続先を 160.79.104.10 から隣の .11 へ振り替える。 この「.10 → .11 の hosts 回避」を詳細な手順書に起こし、GitHub へプッシュして、Windows と Mac の両機から参照できるようにした。

仕上げに、置き場所も含めて Windows 実機のセッションに検分させた。 機体間の引き継ぎ文書を置きそうな claude-backup と dotclaude のリポジトリを直接確認して、PR #33 の手順書（docs/troubleshooting/anthropic-api-ipv4-edge-hosts-workaround.md）に行き着き、全文を読ませた。 実機の hosts の状態と、いまどの IP に繋がっているかまで突き合わせさせた。 手順書は妥当、実機側の判断とも一致し、しかも一歩先まで検証されている。 そういう所感が返ってきた。 issue ファイルには、手順書への相互参照と新しい実測結果も追記させた。 これで両機のどちらで詰まっても、同じ手順書と同じ記録に辿り着ける。

学び

  • エラー文の「a firewall or proxy may be blocking it」を真に受けて PC の中だけ探すと迷子になる。定番の容疑者を先に白にできたから、外側を疑う根拠が立った
  • 全サービスが単一の anycast IP に集約されていると、その IP の不調がそのまま全サービスの不調になる
  • 体感を悪くしていたのは IPv4 側の障害だけではない。IPv6 フォールバックを塞いでいた VirtualBox のフィルターという伏兵がいた
  • 「復旧した」と「復旧が維持できている」は別物。計測を続けたから、維持できていないことに気づけた
  • 回避手順は端末の中のメモにせず、git に置いて両機から参照できるようにする

次にこのエラーを見たら、まず hosts を確認する。 手順書はもう GitHub にある。

#Claude Code #トラブルシューティング #ネットワーク#IPv6#hosts