OpenClaw 的 Telegram 坑
這幾天也遇到 OpenClaw 的底層網路坑，看社群裡也有人遇到一樣的狀況，寫出來分享給也有在架設 Agent 或弄自動化工作流的朋友，幫大家省點 debug 的時間。
如果你最近在串接 OpenClaw 的 Telegram channel，發現訊息突然發不出去也收不到，日誌裡一直跳 Network request failed，先別急著換 Token 或懷疑自己的程式碼，這很有可能是 IPv6 惹的禍。
發生了什麼事？
追蹤了一下底層，主因在於 Node.js 22+ 預設開啟了 autoSelectFamily=true，這會讓系統在發送請求時「優先」嘗試 IPv6 連線。
但實務上，我們常租用的 VPS（例如 Vultr 等）連往 Telegram 的 IPv6 節點經常是不通的。結果就是系統在那邊死等 IPv6 timeout，最後才不甘願地 fallback 到 IPv4，導致嚴重的訊息延遲，甚至直接報錯罷工。
為什麼這很麻煩？
在實際落地應用時，我們其實不是在追求什麼「最炫技」的架構，反而是穩定性、維護成本與失敗率才是決定一個工作流能不能長久運作的關鍵。像這種底層的 Network timeout，往往不會有明顯的錯誤提示，如果不去深挖 Log，真的會找到懷疑人生，我前幾天就花了20美叫 Opus 4.6 追才找出原因。
對於我們這種把 Agent 當作虛擬團隊（像我自己就用 OpenClaw 兜了一組虛擬的 COO、CTO）在跑日常營運的人來說，這種無聲的連線失敗真的是很麻煩。
目前的解法與 Workaround
如果你的環境剛好卡在這，暫時的解法是直接從系統層級關閉 IPv6：
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1重啟 Gateway 後，應該瞬間就暢通了。
但要特別注意：這是一帖猛藥... 如果你機器上有跑 Tailscale 這類高度依賴 IPv6 的網路服務，關掉 IPv6 可能會產生副作用，所以我是決定先把 Tailscale 關掉
目前 OpenClaw GitHub 上已經有很多針對這個問題的 Issue，希望能盡快推動在 OpenClaw 的設定檔裡加上 family: 4 的網路參數選項，讓大家能優雅地指定走 IPv4。
如果你也正好在部署自己的 Agent 團隊，記得多留意一下這個網路環境的坑！
作者：Chi