alireza0X-UI 与 S-UI 核心维护者

值得推荐作者发言

GitHub·2026.11.08 19:00:43（UTC+8）

alireza0：多人共用 WARP 会触发限速，应按需路由

alireza0 判断多人共用免费 WARP 会触发 Cloudflare 限速或丢包，建议保留 direct，只把需要绕过数据中心 IP 封锁的网站路由到 WARP，DNS 在服务器直连解析；同时指出独立网络丢包和客户端 mux 可能造成的其他问题。

作者原文@alireza0

Thanks for the details. The root cause is the setup itself: sending all users' traffic through WARP.

WARP (especially the free plan) is meant for a single device. It is rate-limited, and with several users on it Cloudflare throttles or drops connections. That matches what you see: fine with one or two users, unstable from around six, and fixed once the endpoint is removed. A separate endpoint per user doesn't help, because the limit is on Cloudflare's side.

Websites seeing the server's IP is normal for any proxy and doesn't expose your users. Their own IPs stay hidden either way. The usual setup:

• Keep direct as the final outbound.
• Send only the sites that actually need it (ones that block datacenter IPs, e.g. some Google services or AI sites) to the WARP endpoint with a routing rule.

The same goes for DNS: resolve on the server directly, not through WARP. That isn't a leak; the resolver only sees the server's IP, not your users'.

From the log, apart from that:

• outbound/direct ... i/o timeout didn't go through WARP, so the server's network also drops connections at times. mtr 1.1.1.1 on the server while it's slow would show packet loss.
• process multiplex stream ... use of closed network connection: multiplex is enabled on the client, and on a lossy link mux stalls all streams together. Try turning it off.
• WireGuard is not ready yet only appears while the endpoint is starting, which is expected during your tests.

Your questions: leave Dial Options empty, and revert TCP Fast Open to the default. Neither is related to this.