Connection refused — a firewall or proxy may be blocking it が出るときに、まず確認したいことこの症状は、少なくとも報告上は 2 つの顔があります。ひとつは、毎回のコマンドで API への接続が失敗し、Connection refused — a firewall or proxy may be blocking it (ConnectionRefused) を 10 回試行しても抜けられないケースです。もうひとつは、サブエージェントのストリームが途中で静かに止まり、Agent stalled: no progress for 600s (stream watchdog did not recover) で落ちるケースです。前者は #93041、後者は #87987 にまとまっています。
自分のケースかどうかを切り分けるなら、まず見るべきなのは「Claude Code から API に出る通信だけが失敗しているのか」です。#93041 では、普通の "hello" でも同じエラーになり、しかも毎回再現しています。一方で、同じ報告の中では curl -v https://api.anthropic.com/v1/messages は成功していました。つまり、ネットワーク全体が壊れているわけではなく、Claude Code 側の HTTP クライアント経路に限って失敗している、という切り分けです。
報告にあった実測の確認結果は次のとおりです。
curl -v https://api.anthropic.com/v1/messages succeeds (TLS 1.3 handshake, HTTP/2, expected 405 response, resolved to 160.79.104.10)
このため、少なくとも #93041 の範囲では、「外部ネットワークが完全に死んでいる」というより、「Claude Code の接続処理だけが拒否されている」可能性が高いです。ただし、ここから先の原因までは issue だけでは分かりません。ファイアウォールやプロキシの表示が出ていても、実際にどこで拒否されているのかは未確定です。
#87987 のほうは少し違います。こちらは、複数の subagent を並列で動かしている最中に、転送の途切れが回復せず、600 秒後に watchdog が止めるという報告です。重要なのは、報告者が「laptop-sleep case ではない」と明記している点です。マシンは起きていて、ツール呼び出しも継続していたとされています。なので、単なるスリープ復帰失敗とは別物です。症状としては通信が瞬断したあとに再接続できず、そのままストリームが無音で死ぬ、という見え方になります。
この 2 件を並べて見ると、共通しているのは「一度つながるはずの経路が、途中で回復しない」ことです。ただし、#93041 は起動直後から毎回失敗する再現性の高い接続拒否、#87987 は動作中のストリーム停止です。見た目が似ていても、発生タイミングはかなり違います。
現時点で確認できる範囲では、回避策として「これをやれば直る」と言える情報はありません。実際、#93041 は closed ですが、コメントには「inactive for too long. Please open a new issue if this is still relevant.」という案内しかなく、原因や修正内容は読み取れませんでした。
そのため、このエラーが出たときは、まず次の 2 点だけを押さえるのがよさそうです。
ほかの HTTPS 通信は通るか。
#93041 では curl -v https://api.anthropic.com/v1/messages が成功しています。ここが通るなら、少なくとも回線全体の断ではなさそうです。
失敗が「最初から毎回」なのか、「動作中に止まる」のか。
前者は接続開始側の問題、後者はストリーム維持側の問題として分けて見る必要があります。
もし同じ症状を再現できるなら、再現手順と、curl の結果、Claude Code のエラー全文をそろえて記録しておくのがよさそうです。今回の 2 件だけでは、どのプロキシ設定やどのネットワーク境界が原因かまでは断定できません。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-23T08:51:48+09:00