WS 服务放在 NGINX 后面，根据 4 元组原理（ localhost + [1-2**16), localhost+)，后端一个 listen 端口支持的最大活跃连接数目就是可用端口总数，大家是怎么突破这个限制（在只有一台服务器的前提下），多加一些 listen 端口，还是说规避反向代理？一些负载均衡服务是不是也有同样的问题？假设后端是 MQTT 服务，活跃连接很多，虽然消息频率很低
在单台服务器的情况下，要突破单个后端 listen 端口支持的最大活跃连接数（约为可用端口总数），可以考虑以下几种策略： 1. 增加多个 listen 端口： 增加多个后端端口监听，利用 Nginx 或其他负载均衡工具将请求分散到多个端口，从而提升整体可支持的连接数。每个端口理论上可以使用约 6 万多个源端口，这样可以突破单端口的限制。 2. 使用 IP 地址别名（ IP Aliasing ）： 给服务器配置多个本地 IP 地址（例如 127.0.0.1, 127.0.0.2 等），每个 IP 地址都可以支持一组源端口，配合不同的 listen 端口可以进一步提升总连接数。 3. 开启内核参数调整： 在 Linux 内核参数中调整 net.ipv4.ip_local_port_range ，增大系统可用的源端口范围，并配合 net.ipv4.tcp_tw_reuse 和 tcp_tw_recycle （在合适场景下）减少 TIME_WAIT 端口占用时间。但要注意，这些参数调整可能带来安全和连接稳定性风险。 4. 采用 WebSocket 长连接优化： 对于 MQTT 协议，可以使用 WebSocket 长连接（ Nginx 支持 WebSocket 代理），这样只用占用一次 TCP 连接即可实现长时间的低频消息传输，适合高活跃但低频的场景。 5. 考虑负载均衡服务的方案： 确实，大部分负载均衡服务也会遇到同样的问题。可以选择支持 四层负载均衡（ TCP 直通） 的产品，这类负载均衡可以分散连接到不同 IP 或端口，并能够优化多 TCP 连接处理的效率。此外，负载均衡产品通常会用 SO_REUSEPORT 来实现多端口监听和多进程并发，这样可以增加连接数。 6. TCP Multiplexing 或 HTTP/2, HTTP/3 复用（视协议支持情况）： 如果协议允许，可以考虑 HTTP/2 或 HTTP/3 的多路复用特性，通过复用单个 TCP 连接实现多个请求，这样可以减少活跃连接数的需求。 在高活跃 MQTT 服务的场景下，推荐通过 增加 listen 端口 和 多个本地 IP 组合，配合 内核参数优化 来实现较高的并发连接支持。这些措施有助于在单台服务器上突破连接限制，同时保持连接的低频消息传输。
1. 取消代理 直连后端 2. 通过域名 DNS 轮询,配置到不同服务器上 3. 后端出一个接口, 返回可用的服务器地址列表, 前端再进行长连接 或者 302 到对应服务器 这种做法自由度最高, 可以自定义分配策略
https://github.com/XianwuLin/xianwulin.github.com/issues/26 https://www.iamle.com/archives/1865.html 但是一般不用过多考虑，60000 个连接，1 个服务器首先是网卡带宽和 nginx 达到瓶颈，横向增加 nginx 就行了。
