ERR_CONNECTION_RESET が出るとき、まず見るべき切り分けこの症状は、Claude Code の cloud environment や web sandbox でブラウザ系の通信だけが落ちるときに出ています。報告されているのは、Playwright MCP の browser_navigate や headless Chromium の page.goto() が、どの URL でも net::ERR_CONNECTION_RESET になるケースです。対象は https://example.com や www.google.com のような一般的なサイトでも同じでした。いっぽうで、同じセッション・同じシェル内では curl や Node の fetch、https モジュールが成功している、というのが共通点です。これは #85757 と #73564 に書かれている症状です。
自分のケースがこのクラスタに近いかどうかは、まずここで見分けられます。ブラウザだけが失敗し、同じ時点の curl は通る。しかも失敗が特定サイトに限られず、広く再現する。これなら、サイト側の個別障害よりも、cloud environment 側の経路や Chromium 側の扱いを疑うのが自然です。
issue 側の記述では、Network access = Full でも同じでした。さらに、明示的に --proxy-server を付けても改善しなかった報告があります。コメントには、これは proxy の制限に一致する、という見方がありましたが、少なくとも「ネットワーク設定を Full にするだけ」では直っていません。#85757 では、CONNECT トンネル自体は張れているが、その内側の TLS ハンドシェイクで reset される、という観察も共有されています。そこでは TLS 1.3 に絞った説明が出ていますが、これは issue 報告ベースの話で、こちらで再検証したものではありません。
筆者の環境で取得できた一次情報は、検証日時と OS / Python の確認だけでした。症状そのものを再現したログは手元にありません。記録として残っているのは次です。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-08-27T08:50:24+09:00
このため、ここで書けるのは「こういう条件で報告されている」という整理までです。ERR_CONNECTION_RESET が出たからといって、すぐにサイト障害や証明書エラーと決め打ちするのは早いです。少なくとも今回の issue 群では、curl は同じ URL に届いているのに、Chromium 系だけが落ちています。切り分けの順番としては、ブラウザだけ失敗するのか、非ブラウザの HTTP クライアントも失敗するのかを先に見るのがよさそうです。
現時点では、確立した解決策は issue からは読み取れません。--proxy-server の明示や、環境変数を使った経路の指定、allowlist、Network access = Full は、少なくとも報告された範囲では決定打になっていません。回避策として話題に出ているものもありますが、ここでは実際に裏が取れた内容だけにとどめます。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-08-27T08:50:24+09:00