LMLPHP后院

扫码查看  原文链接 : https://blog.lmlphp.com/archives/964/Questions_about_WebSocket_timeout  来自 : LMLPHP后院

本文揭开 websocket 的 timeout 的神秘面纱。在开发的时候，也就是本地环境，几乎无论多少时间都不会 timeout。

一旦到了正式的网络环境，一直是一分钟断开，因此需要 ping pong 的机制，或者重连接，但是重连接有个不好，就是有时间间隔，你不可能不等个几秒再连接，不然服务器实在是顶不住的。

我遇到的问题是，正式网络环境一开始没有发现问题。

后来第二个应用上线，发现总是一分钟会断开，然后重连接，然后又是一分钟断开。

搞了很多 nginx reverse proxy 方面的配置，发现根本不是那个问题，并且 nginx 的 timeout 一般都很长的。

后来搞了很久，才发现原来是本地代理 clash 的问题，这个一开，铁定一分钟断开。并且我在 clash 的配置文件中，没有找到可以配置超时的地方。

然后关闭了 clash 继续测试，发现时间长了一点，变成了标准的两分钟，难道是两分东...🤦‍♂️

最后 Google 之，发现 cf 确实是有超时的，说是 100 秒，其实我测试真的差不多标准两分钟 120 秒。更标准一点的说法是 两分钟 ➕ 6秒，测试下来的的确确 126 秒。

Cloudflare handles WebSocket connections with a default inactivity timeout of 100 seconds. This means if no data is exchanged over the WebSocket connection for 100 seconds, Cloudflare will terminate the connection. This timeout is not configurable directly within Cloudflare's settings for standard proxied traffic.
Key points regarding Cloudflare WebSocket timeouts:
Inactivity Timeout: Cloudflare's default idle timeout for WebSockets is 100 seconds. This applies to the connection between Cloudflare's edge and your origin server, as well as between the client and Cloudflare's edge.
Keep-Alives: To prevent connections from being terminated due to inactivity, it is recommended to implement a keep-alive or ping-pong mechanism within your WebSocket application. This involves sending small data frames at regular intervals (e.g., every 30-60 seconds) to ensure the connection remains active.
Cloudflare Workers: When using WebSockets with Cloudflare Workers, the timeout behavior can differ. For Workers on the Bundled plan, the connection is limited by the Worker's CPU time. For Workers Unbound, the connection can remain open as long as it's active and the Worker doesn't exceed its memory limits, with an idle timeout typically in the range of 1-10 minutes.
Origin Server Settings: Ensure that your origin server also has appropriate timeout settings for WebSockets, and that they are compatible with Cloudflare's 100-second limit. If your origin server has a shorter idle timeout, it may prematurely close connections.
Troubleshooting: If you experience frequent WebSocket disconnections when using Cloudflare, consider checking browser console errors, verifying correct URL formats (ws:// or wss://), ensuring proper server-side configuration, and disabling potentially interfering Cloudflare features like Rocket Loader.

[2025-11-03T19:19:45+08:00] New client connected Resource id #18, count 1
[2025-11-03T19:19:45+08:00] sleep 1, clients count 1
[2025-11-03T19:21:51+08:00] Client disconnected. Resource id #18
[2025-11-03T19:21:51+08:00] sleep 1, clients count 0

跟上面 AI 说的不太一样，至少说明 ping pong 机制是必须的，因为网络情况实在是太复杂。

设置了 ping 模式的情况，依然不乐观，因为会被掐断连接，时间也在三分钟左右，如下：

[2025-11-03T22:08:49+08:00] Listening for new connections on 127.0.0.1:8081
[2025-11-03T22:09:11+08:00] New client connected Resource id #5, count 1, info {"id":0,}
[2025-11-03T22:09:11+08:00] sleep 1, clients count 1
[2025-11-03T22:12:43+08:00] Client disconnected. Resource id #5
[2025-11-03T22:12:43+08:00] sleep 1, clients count 0
[2025-11-03T22:13:46+08:00] New client connected Resource id #9, count 1, info {"id":0,}
[2025-11-03T22:13:46+08:00] sleep 1, clients count 1
[2025-11-03T22:18:12+08:00] Client disconnected. Resource id #9
[2025-11-03T22:18:12+08:00] sleep 1, clients count 0
[2025-11-03T22:19:16+08:00] New client connected Resource id #12, count 1, info {"id":0,}
[2025-11-03T22:19:16+08:00] sleep 1, clients count 1

必须设置双向 ping pong 模式，目前看起来还比较稳定。

11 月了，蓦然发现，我的 macbookpro 设置了纽约时区慢了一小时，查看资料，原来如此，看来苹果电脑是真细心啊。

纽约处于北美东部时区，通常被称为东部标准时间（Eastern Standard Time，简称EST），其UTC-5:00（西五区）。

纽约的夏令时开始于每年3月的第二个星期日，此时时钟会向前调整1小时，变为UTC-4:00（西四区），这一变更旨在更好地利用夏季的日光。夏令时结束于每年11月的第一个星期日，届时时钟将调回UTC-5:00（西五区）。因此，在夏令时期间，纽约与北京时间的时差为12小时；而在非夏令时期间，这一时差增加至13小时。

这几天没有特别的注意电脑时间，上面写的是第一个星期四，显然还没有到第一个星期四，11 月 1 日是星期六，不过苹果电脑显然是从 11 月开始把 NY 时区变慢一小时了。

不过我还是找到了一些根据，就是时区变化的时间可以根据我的 git 提交记录来确定，好在这几天在提交代码。

commit b7956f9e2b86409a9730e5a5cca8bcc7f1dd1fdc
Author: lin <lin@local>
Date:   Sun Nov 2 01:53:56 2025 -0500

    fix

commit f66c30944a8080ee943948a1df77a3437565ddda
Author: lin <lin@local>
Date:   Sun Nov 2 00:35:19 2025 -0400

    code format

根据上面的变化，可以确定，在 11 月 2 日的 00:35（-4） 到 01:53（-5） 之间时区发生了变化。应该算是 2 号的 0 点发生变化的。从提交记录看，其实早在 2024 年就已经经历过一次，只是当时没有太注意，惭愧。