Wrangler dev 出現 Network connection lost 怎麼查？先做版本 bisect

先看錯誤是在 Worker 還是 dev server#

先把症狀分成三層：

如果只有某一個 endpoint 回 500，其他 request 仍然正常，先查應用程式；如果整個本機 dev server 在第一次錯誤後失去服務，才進入下面的版本與 runtime 排查。

第一步：把版本與執行環境記下來#

Cloudflare 建議在專案內安裝 Wrangler，這樣才能固定版本與回滾。先記錄：

1
pnpm exec wrangler --version
2
node --version
3
uname -a

issue #15002 回報的 regression window 是 wrangler 4.114.0 到 4.118.0，4.113.0 及更早版本在該報告的測試中沒有重現；另一個追蹤 issue #14926 也把 4.114.0／4.115.0 與 Miniflare 版本列為受影響組合。這是特定報告的版本 bisect，不是對所有 Node、作業系統或專案的相容性保證。

若要保存 Wrangler 的本機 log，可以先列出最新檔案：

1
ls -t ~/.config/.wrangler/logs/wrangler-*.log | head -n 1

--log-level debug 仍然值得開啟，但 issue #14926 指出實際的 Network connection lost. 可能只出現在 ~/.config/.wrangler/logs/ 內，終端機本身不一定顯示完整原因。

第二步：用相同程式做版本 bisect#

不要在比較版本的同時升級 Node、修改 lockfile、改 request sequence 或換 CI runner。可以先用一次性執行確認兩個版本的差異：

1
pnpm dlx [email protected] dev
2
pnpm dlx [email protected] dev

對每個版本都做同一組檢查：

1. 啟動同一份 Worker build 或同一個 entrypoint。
2. 等待 dev server ready，再送出相同的 GET、JSON POST 和 urlencoded POST。
3. 記錄第幾次 request 出錯、程序是否退出，以及是否出現 ECONNREFUSED。
4. 在本機 macOS 與 CI Linux 都有問題時，分別保留兩邊的 log，不要混在一起下結論。

只有「程式碼、Node、request sequence 都不變，換 Wrangler 版本才改變結果」時，版本回歸才是合理的工作假設。

第三步：決定是暫時 pin 還是繼續查應用程式#

如果你的最小重現與 issue 報告相同，並且 4.113.0 通過、4.114.0 以上失敗，可以在 dev／CI 暫時固定已驗證版本：

1
pnpm add -D [email protected]

這個 pin 是 issue #14926 作者記錄的 workaround，不是 Cloudflare 宣布的長期修復。固定版本後仍要：

• 把 issue #14926 的狀態與目前使用的版本寫進團隊追蹤紀錄。
• 以你的 Worker、Node 與 runner 重跑 smoke test。
• 了解 pin 會延後 Wrangler 的其他修正，不要無限期停留在舊版本。
• 上游有修正後，重新做同一組版本比較，再決定何時解除 pin。

若 4.113.0 和 4.114.0 都失敗，或錯誤只在你新增某個 binding、middleware、custom build 後出現，就不要套用這個 workaround。回到 Worker log、binding 設定、request body 讀取與應用程式錯誤處理。

CI 特別要檢查 concurrency 與 TLS 噪音#

issue #14926 的重現來自 Linux x64 CI、wrangler pages dev --local-protocol=https、並行瀏覽器流量與 Playwright shards；作者也註明 macOS arm64 沒有重現。這不代表所有 Linux runner 都會中招，但它提醒排錯時要列出：

1
OS / architecture
2
Node version
3
wrangler and miniflare versions
4
wrangler dev or wrangler pages dev
5
--local-protocol and TLS settings
6
number of parallel clients or test shards

如果錯誤只出現在高並行的 CI，先把 shards 或 parallel clients 降到一個做對照，不要立刻把 TLS 證書錯誤當成根因。issue 報告裡的 TLS handshake noise 在正常版本也存在，真正的區別是 runtime restart 後 dev server 能不能繼續服務。

結論：把 Network connection lost 當成需要分流的訊號#

這個錯誤的安全處理順序是：先區分單一 request 失敗與 dev server 崩潰，再記錄 Wrangler／Miniflare／Node／runner，最後用不變的程式做版本 bisect。只有自己的重現與 upstream issue 條件吻合時，才暫時 pin 4.113.0；否則應繼續查 Worker 本身，而不是複製一個與環境無關的降級指令。