在关闭Frp的tcp mux 后上传才正常持续，之前是小文件可以秒传卡100%，大就传一下等待一会儿就报错Network Error（仅使用Frp进行端口转发的情况下）如果再加上Nginx进行反向代理没有写明超时时间，默认60s就更完蛋了，给你报405/502/504等一串错误。
HK 大陆3网直连 200Mbps的VPS做转发，一个30MB的文件1MB分片已经传了十几分钟了，真的逆天啊我很难想想这性能瓶颈到哪里了，哪怕作为下载方的家宽服务器现在也有100Mbps下行，我本地直接5G流量居然还是这么龟速。 纯纯逆天。
折腾这个玩意真的让我力竭了，当然力竭的倒霉蛋也不只我一个，互联网上随手就能搜到类似的问题，而且最终说是解决的实际和没解决也区别不大，依旧是慢如蜗牛。

先来谈谈Frp TCP多路复用的降速问题

看个帖子：tcpmux 会大幅降低链路速度#2987
看完你应该大致明白发生了啥，总之开发者们选择了稳定性，但是这在我的应用场景就很糟糕。
所以我最终选择了关闭TCP MUX。

Nginx 反代对Cloudreve的影响

首先，我刚才提过Nginx对前后端的默认的连接超时都是60s一超时就给前端返回504，所以你要么60s内传完，要么保障断开连接后自动重连。
当然，我们还有个更具备实操价值的办法😉：

  location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host; 
        proxy_redirect off;
        proxy_pass http://127.0.0.1:5212;  
        proxy_request_buffering off; # 禁用反向代理缓存
        proxy_read_timeout 3600s;   # 等待后端响应超时
        proxy_send_timeout 3600s;   # 发送请求体给后端
        client_body_timeout 3600s;  # 接收客户端请求体
        send_timeout 3600s;         # 发送响应给客户端

        client_max_body_size 0;     # 0 表示不限制请求体大小
    }

分片大小

在带宽足够的情况下，为了充分吃满带宽分片大小应该尽可能的大以提高[所求数据传输时间/协议开销时间]的值，拆分成小块发送意味着花费更多的时间在协议开销上。具体大小应该根据你自己的各级服务器带宽决定，如果带宽本身就很低或者波动明显，就适当调小维持稳定上传状态。
对于我的200Mbps上行的Frps和30上/100Mbps下的Frpc 我选择的分片大小是16MB。

Frps与Frpc 之间的协议效率

在理想的情况下，QUIC一定是最好的选择，如果网络波动明显只能退选KCP。但是考虑到实践中某些运营商对UDP流量极端的QoS策略，我只能选择TCP和基于TCP的协议。
在某些特殊环境下，开启流量加密是你不得不做的选择，但是如无必要加密和压缩两个都没有必要开，特别是设备cpu性能明显羸弱的情况下，开启流量压缩没有任何意义。

最后，看看更接近操作系统底层的地方

Linux之TCPIP内核参数优化

懒人方案：决定24H不睡迎接中秋节——顺便修一修linuxuser.site邮件服务器的严重不可用问题

2026-08-09更新

明确一件事：FRP转发降速的根本原因你的稳定网络带宽并没有像IDC承诺的那样高！

通过iperf3 反复测速发现，NAS和Frp Server的链路速度中ipv4 udp是延迟和速度最佳的，因此我选择避免NAS frpc客户端使用ipv6连接 服务器。
其次，iperf3以不同限速条件测试还发现：
上行（本地→服务器）：在 50Mbps 时丢包率仅 0.038%，但达到80Mbps时丢包率骤升至 28%，说明上行安全极限约为 50Mbps。
下行（服务器→本地）：虽然极限能跑到 90Mbps 左右，但丢包率达 8.6%，为了稳定性调整限制在 70Mbps 以内。
一旦超出速率就面临30%的丢包率。为了避免高丢包对链路连接稳定性和重传概率的干扰，我选择切换到KCP模式，固定速率48Mbps，同时发现由于早前禁用TCP连接复用导致正常环境下访问cloudreve 短时间内静态资源和API请求会占用大量连接出现 frp备用连接池不足的问题。
2026-08-09 00:07:05.086 [E] [client/control.go:144] [da4d5ef29b0299e1] StartWorkConn contains error: work connection pool is full, discarding

因此tcp连接复用还是要开启的，当然也许理论上坚持手动调大预备连接池也能解决问题，但是考虑到国内运营商对家宽的连接数限制，最好降低连接数避免过高连接数触发QoS 影响链路稳定性。
同时为了降低对NAS G4600 CPU较为有限的资源占用，我没有采取vHost 代理模式，而是直接将cloudreve 的5212端口tcp通过FRP代理到HK Frp Server本地，然后原地建立Nginx反代，将TLS开销完全丢给HK Frp Server。
在经过上述调整后，测试上传的100MB文件上传进度均匀稳定，没有卡在100%，并且基本可以顶至预设的6MB/s限速最终稳定在5Mbps。（也符合百兆家宽普遍的上下行规律 QoS限制内的冗余值设置在40~50Mbps 实际机房链路预期为30~40Mbps。）

为什么同为UDP 谷歌宣传更好的QUIC反而不如KCP？

QUIC 强制 TLS1.3 加密握手开销大，且其默认的拥塞控制算法CUBIC基于丢包设计，一旦检测到丢包会激进地降低发送速率。家宽受运营商跨网和固有机房节点设备性能限制本就处于较高丢包率的网络环境中，CUBIC 会频繁地触发降速机制，导致吞吐量骤降无法像 KCP 那样快速重传，导致转发Cloudreve流量时出现严重的连接超时和假死问题。
具体配置分享如下：

Frpc 配置部署于 NAS 中国联通家宽

serverAddr = "149.104.5.21"
serverPort = 7000
auth.token = "null"

# 全局传输协议
transport.protocol = "kcp"
#transport.tcpMux = false

# ====== 代理列表 ======

# -------------------
# xfox.fun 主站
# -------------------
[[proxies]]
name = "xfox.fun"
type = "http"
localIP = "127.0.0.1"
localPort = 80
customDomains = ["xfox.fun", "www.xfox.fun"]
transport.bandwidthLimit = "6MB"

# -------------------
# linuxuser.site 主站
# -------------------
[[proxies]]
name = "linuxuser.site"
type = "http"
localIP = "127.0.0.1"
localPort = 80
customDomains = ["linuxuser.site", "www.linuxuser.site"]
transport.bandwidthLimit = "6MB"

# -------------------
# NAS 页面
# -------------------
[[proxies]]
name = "nas.xfox.fun 5212"
type = "tcp"
localIP = "127.0.0.1"
localPort = 5212
remotePort = 5212
#transport.useEncryption = true
#transport.useCompression = true
#如果你认为你的客户端设备性能较强你可以考虑开启压缩，但是个人不推荐同时启用压缩和加密（理论上显著增加链路延迟）
transport.bandwidthLimit = "6MB"

Frps 配置 部署于HK三网直连优化服务器

indAddr = "::"
bindPort = 7000
vhostHTTPPort = 按需随意
#vhostHTTPSPort = 8443

# 原 QUIC 监听端口（如果你不再用 QUIC，可以注释掉；保留也无妨，但本次客户端不用）
# quicBindPort = 7000

# KCP 监听端口（与 bindPort 一致，这样客户端无需指定额外端口）
kcpBindPort = 7000

auth.token = "null"
#transport.tcpMux = false
# 以下配置随意
webServer.addr = "0.0.0.0"
webServer.port = 7500
webServer.user = "你的用户名"
webServer.password = "你的密码"

Nginx 反代配置 部署于HK三网直连优化服务器

server {
    listen 80;
    listen [::]:80;
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name nas.xfox.fun;
    http2 off;
    # SSL 证书路径按需随意，以下示例仅供参考
    ssl_certificate /root/www/all_xfox.fun/fullchain.pem;
    ssl_certificate_key /root/www/all_xfox.fun/privkey.pem;

    # ========== SSL 配置 ==========
    ssl_protocols TLSv1.2 TLSv1.3;  
    ssl_prefer_server_ciphers on;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
    ssl_ecdh_curve X25519:secp384r1;  
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;
    ssl_stapling on;
    ssl_stapling_verify on;
    # ====================================

    root /var/www/tv.linuxuser.site;
    index index.html;


    location / {
    # ========== 基础代理头 ==========
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_redirect off;

    # ========== 后端地址 ==========
    proxy_pass http://127.0.0.1:5212;

    # ========== 超时设置 ==========
    proxy_request_buffering off;
    proxy_read_timeout 3600s;
    proxy_send_timeout 3600s;
    client_body_timeout 3600s;
    send_timeout 3600s;
    client_max_body_size 0;

    proxy_connect_timeout 75s;                # 连接后端超时（默认60s，适当延长）
    proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
    proxy_next_upstream_tries 3;              # 允许重试3次
    proxy_next_upstream_timeout 30s;          # 重试总时间限制
    proxy_http_version 1.1;
    proxy_set_header Connection "";

           }
}

写在末尾

TCP连接复用在运营商QoS环境下本身并不稳定，中途可能导致连接中断，进一步造成上传文件卡住假死的问题。因此你应该根据实际iperf3测试得到的低丢包率稳定的上下行带宽完成配置。理论上，TCP连接复用也并不能彻底解决连接池占满的问题，所以你也可以尝试关闭TCP连接复用并继续增大连接池数量到适宜水平。

标签: none

添加新评论