Claude Codeの「Socket is closed」エラーの原因と対処
ストリーミング応答の途中で接続が切れる「Socket is closed」エラーの原因と、v2.1.214での挙動変化、似た接続エラーとの見分け方をまとめます。
「Socket is closed」は、ストリーミング応答を運ぶ接続が、応答の受信中に切断されたときに出るエラーです。原因として挙げられているのは、Windows環境の企業プロキシが確立済みのトンネルを応答の途中で切ってしまうケースです。v2.1.214以降のClaude Codeに更新して、メッセージを送り直すのが示されている対処です。
「Socket is closed」の意味と主な原因
Socket is closedは、ストリーミング応答を運ぶ接続が応答の途中で閉じられたことを指すエラーです。Claude Codeはモデルの応答をストリーミングで受信します。接続そのものは一度確立できているのに、応答が届き切る前にソケットが閉じられる点が特徴です。
接続を確立できない「Unable to connect to API」系のエラーとは、原因の層が違います。公式が最も多い原因として挙げるのは、Windows上の企業プロキシが確立済みのトンネルを応答の途中で落とすケースです。プロキシが落とす条件(時間やデータ量)までは公式に書かれていないため、手元のログで確かめるしかありません。
v2.1.214より前と以降で挙動が変わる
対処の中心はバージョンです。v2.1.214より前は、このエラーは再試行されず、Socket is closedを含むエラーでターンが止まっていました。v2.1.214以降は、切断が起きた段階に応じて「再試行する」「出力を残す」「ターンを終える」のどれかになります。
v2.1.214(2026年7月18日)の変更履歴には、もう1件関連する変更があります。古くなった接続のエラーが出た後はkeep-alive接続の再利用を止め、再試行では新しいソケットを開く、というものです。使い回した古い接続が、再送のたびに同じ失敗を繰り返さないための変更です。
つまりこのアップデートは、再試行の回数だけでなく、画面に出るメッセージも変えました。応答がまだ何も完了していない段階の切断は裏側で再送されるので、生のSocket is closedを目にする場面は減ります。
切断の段階で変わる3つの扱い
Claude Codeは一時的な失敗を最大10回、指数バックオフで再試行します。ただし、応答の途中で起きた失敗にこの回数が一律で使われるわけではありません。段階ごとの扱いは次のとおりです。
切断が起きた段階ごとの扱い
思考も完了していない段階
フルの再試行の対象です。テキストが流れ始めていても、思考が完了していなければこの区分に入ります。スピナーに
Retrying in Ns · attempt x/yのカウントダウンが出たまま再送され、ターンはそのまま続きます。思考後・出力の開始前
素早く最大2回だけ再送されます。切れ続けると「Connection lost before a response was produced」でターンが終わります。
出力が始まった後
文章やツール呼び出しが完成した後は、再試行されません。思考を終えて文章やツール呼び出しを書き始めた後も、この区分に含まれます。完成済みの出力を残してターンを進め、「The response above may be incomplete」の注記が付きます。同じリクエストの再送で、実行済みのツール呼び出しが二重に走るのを避けるためです。
この区分は、Socket is closed専用ではなく、ドロップした接続全般に使われます。ストリームが止まる(接続は開いたまま届かなくなる)場合も、同じ段階分けで扱われます。段階で結果が分かれる点は同じですが、停滞の再送は10回の枠の外で1回だけです。
今すぐ試せる対処
公式の手順は、更新してメッセージを再送することです。
Socket is closedが出たときの順序
- 1
バージョンを確認する
claude --versionで確認します。v2.1.287で実行すると2.1.287 (Claude Code)と表示されました。セッション内なら/statusでもバージョンを確認できます。 - 2
v2.1.214未満なら更新する
claude updateを実行します。claude update --helpの説明は「Check for updates and install if available」で、upgradeという別名もあります。 - 3
メッセージを再送信する
更新後に同じメッセージを送り直します。
- 4
続くならプロキシ側を調べる
同じプロキシ配下で失敗が続くなら、公式は「Unable to connect to API」の確認手順と、ネットワーク設定の見直しを案内しています。
claude --version
claude update「Unable to connect to API」の確認手順の第一歩は、同じシェルでcurl -I https://api.anthropic.comを実行することです。PowerShellでは組み込みの別名を避けるためcurl.exe -I https://api.anthropic.comと書きます。これが通るのにClaude Codeだけ失敗するなら、原因はネットワークそのものより、ランタイムとネットワークの間にあることが多いと案内されています。確認先は4つあります。
ANTHROPIC_BASE_URLが設定されていないか。echo $ANTHROPIC_BASE_URLで見ます(PowerShellではecho $env:ANTHROPIC_BASE_URL)。すでに止まったローカルのプロキシやゲートウェイを指す値が残っていると、curlはAPIに届くのにConnection refusedになります- LinuxとWSLでは、
/etc/resolv.confに到達できないネームサーバーが残っていないか - macOSでは、切断またはアンインストールしたVPNクライアントがトンネルのインターフェースやルーティング規則を残すことがあります。
ifconfigで古いutunが残っていないかを見ます - Docker Desktopなどのコンテナ実行環境が外向きの通信を横取りすることがあります。いったん終了して再試行すれば、切り分けられます
疎通確認が短い1往復で済むのに対し、ストリーミングは長く開いたままの接続です。この違いから、ストリーミング接続の扱いだけが違う可能性も疑えます。これは公式の案内ではなく、この記事の推論です。
更新後も同じプロキシ配下で失敗が続くなら、Claude Codeプロキシ設定で環境変数と許可リストを見直します。アップデート手順そのものはClaude Codeアップデートの方法にあります。
どの表示が出たかで切断の段階を読む
Claude Codeが出す接続系のメッセージは複数あり、切れたタイミングで文面が変わります。Socket is closedという文字列だけで原因を決めつけると遠回りになります。
| メッセージ | 切れた段階 | 再試行 |
|---|---|---|
| Socket is closed | 切れた段階接続が閉じた(上の3区分に従う) | 再試行v2.1.214以降は段階に応じる |
| Connection lost before a response was produced | 切れた段階思考後・出力開始前 | 再試行素早い再送を最大2回し、失敗後にこの表示 |
| Connection lost mid-response | 切れた段階出力が始まった後(完成した分がある場合を含む) | 再試行しない(完成分を保持) |
| The response stalled before a response was produced | 切れた段階思考後・出力開始前に、停滞が2回続いた | 再試行停滞の再送は1回だけ |
| Unable to connect to API | 切れた段階接続の確立自体に失敗 | 再試行断続的な失敗は自動再試行される |
v2.1.227より前は、文面が違っていました。Connection lost before a response was producedはConnection closed while thinking, before producing a response、Connection lost mid-responseはConnection closed mid-response、The response stopped arrivingはResponse stalled mid-streamと表示されていました。古い版で見た文面を検索したときの手がかりになります。
「The response above may be incomplete」の注記には、原因を示す変種が6つあります。主なものを挙げます。
Server error mid-response:ストリームの途中で5xxや過負荷のエラーが届いた(v2.1.199以降)Connection lost mid-response:接続が切れた。プロキシやゲートウェイが応答本文を途中で正常終了させたときにも出るYour computer went to sleep mid-response:ストリーミング中にPCがスリープしたThe response stopped arriving:接続は開いたまま、データが届かなくなった
3つ目のConnection lost mid-responseは、プロキシが関わる点でSocket is closedと近い関係にあります。公式は、プロキシが応答本文を途中できれいに閉じた場合もこの変種になると書いています。プロキシ配下では、同じ原因でもSocket is closedになる場合と、この変種になる場合があります。
接続は開いているのに止まる場合の見分け方
Socket is closedは接続が閉じられるエラーですが、接続が開いたまま何も流れなくなる故障は別の仕組みで扱われます。応答ストリームに20秒間データが届かないと、スピナーにWaiting for API response · will retry in … · check your networkが出ます。これはまだ失敗ではなく、停滞した接続を打ち切るまでのカウントダウンです。
打ち切った後の挙動は、切断と同じ段階分けに従います。完成済みの出力があれば保持され、「The response stopped arriving」の注記が付きます。
ストリームの停滞を監視するタイマーは4種類あります。既定値は次のとおりです。
| タイマー | 打ち切る条件 | 既定(直接のAnthropic API) |
|---|---|---|
| 最初のバイトの期限 | 打ち切る条件リクエスト送信後、レスポンスヘッダーが届かない | 既定(直接のAnthropic API)180秒(リクエスト本文32KBごとに1秒加算) |
| イベント単位 | 打ち切る条件応答イベントが解釈できない | 既定(直接のAnthropic API)300秒 |
| バイト単位 | 打ち切る条件SSEのkeep-alive pingを含め、バイトが何も届かない | 既定(直接のAnthropic API)180秒 |
| 本文のアイドル | 打ち切る条件5分間バイトが届かない | 既定(直接のAnthropic API)他プロバイダー向け(5分) |
プロキシが応答をまとめて溜めてから流す(バッファリングする)構成では、「閉じる」のではなく「静かになる」形で現れる可能性があります。その場合に見えるのは、Socket is closedよりThe response stopped arrivingのほうです。これは公式の記述ではなく、この記事の推論です。
イベント単位とバイト単位のタイマーは、CLAUDE_STREAM_IDLE_TIMEOUT_MSでまとめて変えられます。5分未満は5分に引き上げられ、バイト単位は30分が上限です。バイト単位だけを変えるCLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MSは、10秒から30分の範囲に収められます。本文のアイドルはAPI_FORCE_IDLE_TIMEOUTで、0なら無効、1なら全プロバイダーで有効になります。
プロキシ設定が読み込まれているかを確認する
更新しても続くときは、Claude Codeがプロキシ設定を意図どおり読んでいるかを先に確かめます。環境変数はHTTPS_PROXY(HTTPSプロキシ向け)とHTTP_PROXYで、小文字の変種も使えます。優先順はhttps_proxy、HTTPS_PROXY、http_proxy、HTTP_PROXYで、最初に設定されているものが採用されます。プロキシを通したくない宛先はNO_PROXYに書きます。
セッション内で/statusを開くと、Proxyの行に有効なプロキシのURLが出ます。解釈できない値は無効として無視されると表示されます。ネットワーク設定の読み込みはデバッグログでも確認できます。ただしClaude Codeは、ほとんどの設定を読み込み時に検証しません。誤ったプロキシのアドレスや証明書のパスは、後続のリクエストで接続エラーや証明書エラーとして初めて表れます。起動時に検査されるのは、プロキシURLが解析できるかどうかだけです。http://を落とした値のように解析できないと、起動がエラーで止まります。
許可リストの確認も欠かせません。api.anthropic.comはAPIリクエストに必要で、アカウント認証にはclaude.aiとplatform.claude.comが要ります。ストリーミングの切断が起きるのは認証より後の段階なので、まずapi.anthropic.comへの経路を疑います。許可すべき宛先は、ネットワーク要件の表に一覧があります。
プロキシが認証を求める構成では、HTTPS_PROXYにユーザー名とパスワードを含むURLを書く方式も公式に載っています。パスワードがシェルの履歴や設定ファイルに残るため、扱いには注意が必要です。
原因を絞るためのログの取り方
切り分けに迷うときは、デバッグログを取るのが手がかりになります。claude --debugで起動すると、デバッグログがセッションごとに残ります。ネットワーク設定の確認手順でも、ログはターミナルではなく~/.claude/debug/<session-id>.txtに出ると案内されています。保存先を指定したいときは--debug-file <path>を使います。このオプションは暗黙にデバッグモードを有効にし、v2.1.287のclaude --helpにも載っています。
claude --debug-file ./claude-debug.logログに接続エラーの詳細が残っていれば、社内のネットワークチームに渡す材料になります。その際は、エラー文字列だけでなく「ストリーミング応答の途中で切断される」という症状を添えると、プロキシの設定を見る担当者に伝わりやすくなります。
よくあるつまずき
- プロキシ側の設定を疑う前に、まずバージョンを確認します。v2.1.214より前は自動で再試行されません
-pなどの非対話実行では、ツール呼び出しを含まない途中切れの応答なら、Claude Codeが続きを最大3回まで自動で促します(v2.1.246以降)。「The response above may be incomplete」が出るのは、それを使い切った後です- 「The response above may be incomplete」が出たときは、完成済みのツール呼び出しはすでに実行されています。再送の前に、途中までの結果を確認します
まとめ
出たメッセージの文面で、切断が応答のどの段階で起きたかが分かります。更新後も同じプロキシ配下で続くなら、次に調べるのはプロキシがストリーミング接続を維持できているかどうかです。