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はモデルの応答をストリーミングで受信しており、TCP接続自体は一度確立できているのに、応答が届き切る前にソケットが閉じられる点が特徴です。接続そのものが確立できない「Unable to connect to API」系のエラーとは原因の層が違います。
最も多い原因は、Windows上の企業プロキシが確立済みのトンネルを応答の途中で切断することです。プロキシがストリーミング接続を長時間保持する設計になっていない場合、一定時間や一定データ量を超えたところでトンネルを強制的に閉じることがあります。ストリーミング接続をうまく扱えないVPNクライアントやセキュリティアプライアンスが、同じ切断を引き起こすケースも見られます。
v2.1.214より前と以降で挙動が変わる
対処の中心はバージョンです。v2.1.214で、このエラーの扱いそのものが変わりました。
| バージョン | Socket is closedが出たときの挙動 |
|---|---|
| v2.1.214より前 | Socket is closedが出たときの挙動再試行されず、Socket is closedを含むエラーでターンが即座に終了する |
| v2.1.214以降 | Socket is closedが出たときの挙動応答の進み具合に応じて再試行するか、それまでの出力を残してターンを終える |
v2.1.214以降では、Socket is closedという生のメッセージ自体を目にする場面が減ります。切断がどの段階で起きたかによって扱いが分かれる仕組みで、詳しい区分は次の節で説明します。応答がまだ何も完了していない段階の切断はフルのリトライ予算で裏側で再送され、画面には何も表示されません。思考は終えたが文章やツール呼び出しの出力がまだ始まっていない段階の切断は、素早く最大2回まで再送され、それでも切れ続けると「Connection lost before a response was produced」という別のメッセージでターンを終えます。つまりこのアップデートは、再試行の回数だけでなく「どのメッセージがユーザーに表示されるか」自体を変えています。
Claude Codeの自動リトライが対象にする範囲
Socket is closedのようなドロップ接続は、Claude Codeの自動リトライの枠組みの中で扱われます。仕組みを知っておくと、なぜバージョンで挙動が変わるのかが分かります。
Claude Codeは一時的な失敗を最大10回、指数バックオフをかけながら自動的に再試行します。ただしこの回数がすべての失敗に一律で適用されるわけではなく、切断が起きた段階によって3つに分かれます。①思考を含め応答のどの部分も完了していない段階の切断は、フルのリトライ予算の対象です(テキストが流れ始めていても、思考が完了していなければこの区分に入ります)。②思考を終えた後、文章やツール呼び出しの出力がまだ始まっていない段階の切断は、素早く最大2回だけ再送する専用の扱いになります。③文章やツール呼び出しの一部がすでに完成した後の切断は再試行の対象外で、完成済みの出力を保持したままターンを終えます。同じリクエストをそのまま再送すると、すでに実行済みのツール呼び出しが二重に走ってしまうためです。
v2.1.214より前は再試行されず、Socket is closedを含むエラーでターンが終了していました。v2.1.214以降は上記の区分に沿って再試行されるようになりました。
今すぐ試せる対処
対処はバージョンを確認して更新する、この1点に絞れます。
claude --version
claude update更新後にメッセージを再送信すれば、多くの場合はそのまま復帰します。/statusを実行すればインストール済みバージョンをインタラクティブセッション内でも確認できます。更新後も同じ症状が続くなら、疎通確認とストリーミング接続とでプロキシの扱いが違う可能性を疑います。curl -I https://api.anthropic.comが通るのにClaude Codeだけ失敗するなら、ストリーミング接続そのものがプロキシで維持できていない可能性を疑います。
更新後も同じプロキシ配下で失敗が続く場合は、根本原因がプロキシ側のトンネル維持にあるため、Claude Codeプロキシ設定の環境変数とファイアウォール許可リストを見直します。ストリーミング接続(SSE・長時間接続)を許可していないプロキシは、Claude Code側をいくら更新しても同じ切断を繰り返します。アップデート手順自体の詳細はClaude Codeアップデートの方法にまとめています。
似た接続エラーとの見分け方
Claude Codeが表示する接続系のエラーは複数あり、Socket is closedという文字列だけを見て原因を決めつけると遠回りになります。切れたタイミングによって表示されるメッセージが変わるため、まず見分けます。
| メッセージ | 意味 | 再試行 | 主な原因 |
|---|---|---|---|
| Socket is closed | 意味ストリーミング応答の途中で接続が切れた | 再試行v2.1.214以降のみ | 主な原因Windowsの企業プロキシがトンネルを途中で切断 |
| Connection lost before a response was produced | 意味思考終了後・出力開始前に切れ、素早い再送も失敗した | 再試行最大2回のみ | 主な原因Socket is closedと同じ種類の切断が別のタイミングで発生 |
| The response above may be incomplete | 意味出力の一部が届いた後に接続が切れた | 再試行されない(部分出力を保持) | 主な原因ネットワーク断・PCのスリープ・サーバー側エラー |
| Unable to connect to API | 意味TCP接続自体が確立できない | 再試行一時的な失敗のみ | 主な原因インターネット未接続・VPNによる遮断・プロキシ未設定 |
4つとも根っこは「接続が不安定」という同じ症状ですが、切れたタイミングで表示が分かれます。Socket is closedと「Connection lost before a response was produced」は、同じ種類の切断がストリームのどの段階で起きたかの違いです。応答が20秒以上届かないときは、切断そのものではなくWaiting for API response · will retry in … · check your networkという別の待機バナーが先に出ます。これは接続がまだ失敗していない段階の表示で、Socket is closedとは別の監視の仕組みです。
「The response above may be incomplete」にはさらに内訳が分かれます。サーバー側の一時エラーが原因のケース、接続そのものが切れたケース、パソコンがスリープしたケース、データが途中で届かなくなったケースの4種類で、表示される文言が変わります。Socket is closedとの違いは、これらがすでに一部の応答が完成した後の切断だという点です。完成済みの出力を残したままターンが終わるので、何も表示されずに再試行されるSocket is closed(v2.1.214以降)よりも、読者にとって復旧の手触りが分かりやすくなっています。
よくあるつまずき
- プロキシ側の設定を疑う前に、まずバージョンを確認します。v2.1.214より前のまま何度再送信しても改善しません
- headless(
-p)実行やCIジョブでは、エラーがログの奥に埋もれて気づきにくいことがあります。終了コードだけでなく出力メッセージも確認します - 原因の切り分けに迷ったら
claude --debugでデバッグログを取り、接続まわりの記録を確認します。ログの出力先は~/.claude/debug/<session-id>.txtです - 社内ネットワークチームに相談する際は、エラー文字列だけでなく「ストリーミング応答の途中で切断される」という具体的な症状を伝えると原因究明が早まります
よくある質問
毎回同じタイミングで切断される場合も原因は同じですか
更新してもなお、毎回ほぼ同じ経過時間や同じデータ量あたりで切断されるなら、特定のネットワーク機器がタイムアウト値やバッファサイズで機械的にトンネルを切っている可能性が高くなります。ランダムなタイミングで起きる切断とは切り分け方が変わり、その機器の設定を直接疑う根拠になります。
Windows以外の環境でも起きますか
公式ドキュメントが名指ししているのはWindows上の企業プロキシですが、原因は「ストリーミング接続を途中で切るネットワーク経路」です。同種の挙動を取るVPNやセキュリティアプライアンスがあれば、他のOSでも起こり得ます。
このエラーで進行中の作業やデータは失われますか
v2.1.214より前では、ターンがエラーで終了するため送信中だったメッセージは失敗として扱われ、再送信が必要です。v2.1.214以降でストリームの後半まで進んでいた場合は、Claudeが完了済みの出力を保持したまま「The response above may be incomplete」で終わることもあります。破壊的な操作やデータ損失を伴うエラーではありません。
プロキシ側の設定を変える必要はありますか
必須ではありません。この修正はClaude Code側の再試行ロジックの変更なので、クライアントを更新するだけで多くの環境が復帰します。プロキシがトンネルを切ること自体を止められる立場にあるなら、根本対策としてプロキシのタイムアウトやkeep-alive設定もあわせて確認する価値があります。
デバッグログではどこを見ればいいですか
claude --debugで起動すると、接続エラーが起きた際の詳細な理由がデバッグログに記録されます。出力先は~/.claude/debug/<session-id>.txtで、--debug-file <path>で保存先を変えることもできます。Socket is closedという文字列自体がログに残っていれば、それが原因を絞り込む最初の手がかりになります。同じ症状が繰り返される場合は、このログを社内ネットワークチームへの報告にそのまま添付できます。
まとめ
Socket is closedへの対処はシンプルです。v2.1.214以降に更新し、メッセージを再送信します。更新後も同じプロキシ配下で繰り返すなら、疑うべきはClaude Code側ではなくプロキシのストリーミング接続維持です。