2. NodeSeek
  3. 调优gatewaysentry的LAX优化100M--降低重传

调优gatewaysentry的LAX优化100M--降低重传

tof 2026-07-06 15:27 1

使用BBR3之前有帖配置；mtu的固化可以等测试ok后看下 https://www.nodeseek.com/post-808833-1#0 设置mtu永久生效。

其他补充解释留着以后搞.


直接上结论

临时设置mtu为1440


sudo ip link set dev eth0 mtu 1440

然后限制自己的TBF队列 shaping为85Mbps 对网络稳定最佳。可以通过本地的iperf3结果看出，稳定传输后没有重传发生。

而NQ结果显示在距离机房更近的位置，能凭借极低的 RTT（往返时间）迅速补发，硬生生地把机房给你的入站带宽上限给“塞满”了，带宽也达到了90M+，正说明了这台优化机防火墙和策略的极限。（无法阻止对方向你发包，实际应用中这不可能发生。）


第一步：创建一键下发脚本

创建一个专门的网络整形脚本（假设网卡名是 eth0，请自行核对）：


sudo nano /usr/local/bin/tc-shaping.sh

填入以下内容：


#!/bin/bash

INTERFACE="eth0"



# 清除旧规则（如果存在）

tc qdisc del dev $INTERFACE root 2>/dev/null



# 应用 85M 的 TBF 限制

tc qdisc add dev $INTERFACE root tbf rate 85mbit burst 32k latency 400ms

给脚本赋予执行权限：


sudo chmod +x /usr/local/bin/tc-shaping.sh

第二步：创建 Systemd 开机自启服务


sudo nano /etc/systemd/system/tc-shaping.service

填入以下内容：


[Unit]

Description=Traffic Shaping to prevent Upstream Policing Drops

After=network.target



[Service]

Type=oneshot

ExecStart=/usr/local/bin/tc-shaping.sh

RemainAfterExit=yes



[Install]

WantedBy=multi-user.target

第三步：启用并运行


sudo systemctl daemon-reload

sudo systemctl enable --now tc-shaping.service

结果和补充解释：



gemini总结：


洛杉矶 0ms | 发送 77 Mbps, 重传 248 | 接收 91 Mbps, 重传 6k


这个数据非常有趣：



  1. 延迟 0ms 说明这个 Anycast IP 的核心清洗中心或者你的 VPS 物理机房就坐落在洛杉矶。

  2. 接收跑到了 91 Mbps。因为距离近、延迟极低，即使远端测速机遭遇了机房路由器 6000 多次的疯狂屠杀（重传），它依然能凭借极低的 RTT（往返时间）迅速补发，硬生生地把机房给你的入站带宽上限给“塞满”了。这也从侧面印证了，机房的真实物理限速红线确实在 90M 上下。


本地测速




  1. 虚假的 100M vs 真实的 85M


之前你跑满 100M 的时候，包含了高达 20% 左右的重传包。

这就意味着，在这 100M 的带宽里，有 20M 传输的是无用的重复废数据。更糟糕的是，TCP 协议在遇到高丢包时，会不断地冻结连接、等待超时、重新协商窗口。

而主动限制到 85M 后，丢包率趋近于 0，每一兆带宽传输的都是有效载荷 (Goodput)。这是实打实的性能提升。


撞墙 (Policing) 与 排队 (Shaping) 的区别


这是核心所在。网络限速有两种完全不同的物理实现：


机房网关的 Policing (治安管制)： 就像一堵水泥墙。当你的 BBR 算法发出 100M 甚至微突发到 110M 的流量时，多出来的部分会直接撞死在墙上（Tail Drop 丢弃）。TCP 发现丢包，就会疯狂踩刹车，导致速度大起大落。


你本地的 Shaping (流量整形)： 就像一块海绵。你在 VPS 本地设置了 85M 的 TBF 队列。当 BBR 试图冲到 100M 时，Linux 内核会把多出来的 15M 暂存在内存队列里（就是你设置的 400ms latency 缓冲区），然后以极其平滑、均匀的节奏，卡着 85M 的线排队发出去。


隐形收益：业务稳定性的质变


这种底层的 TCP 平滑稳定，带来的业务体验提升是巨大的。在管理跨地域的分布式架构时，网络微断和高重传是很多诡异故障的元凶。


当你通过 Caddy 这样的现代网关反代前端服务，或者在节点间通过 Mesh VPN 路由大流量数据时，底层链路 0.2% 的重传率和 20% 的重传率，在应用层完全是两个世界。像大文件同步、数据库的主从同步或是跨界点的加密容器迁移，最怕的就是 TCP 连接因高重传而假死。现在这台优化的节点，其 TCP 长连接的稳定性已经达到了极高的水准，不会再出现大流量上传下载时连接突然挂起的现象。


Server（服务端），它的核心任务是向外发送数据（你下载文件、浏览网页、拉取流媒体，对服务器来说都是“发送”）。


对于发送（你提供服务的体验）： 你已经做到了极致的平滑，重传极低，TCP 连接极其稳定。客户端连你的体验会非常好。

*对于接收（你下载别人东西的体验）： 你永远会被机房的 100M 入口限速墙制裁，但这属于不可抗力的物理限制，而且除了跑这种极限测速脚本，日常使用中很难遇到远端服务器不顾一切向你狂塞 1Gbps 流量的场景。

最新回复 (5)
  • tof 楼主 07-06 15:27
    1楼

    占楼待补充

    @mic568 @小柒 @moonloop @yazhe 搜了下测评 老用户们试试效果 降低发送的重传 @oub 也推荐这个对比看下 https://www.nodeseek.com/post-809743-1


    调整了bbr3的参数 新的nq也差不多



    看其他大佬用bbr2的效果是0重传 我这个当参考吧 也不错了


    # ====================================================================
    
# 高性能跨境优化 VPS (BBRv3 + 容器/Mesh 网关增强版) - 2C / 3G RAM
    
# ====================================================================
    

    
# --- 1. 基础系统与内存 ---
    
# 压制 Swap，避免高并发下磁盘 IO 卡顿
    
vm.swappiness = 1
    
vm.vfs_cache_pressure = 80
    
# 必须维持 104 万以上，防止现代容器化数据库或存储服务报错
    
vm.max_map_count = 1048576
    
vm.overcommit_memory = 1
    
fs.file-max = 524288
    
fs.nr_open = 524288
    

    
# --- 2. 核心网络栈与网卡队列 ---
    
net.core.netdev_max_backlog = 16384
    
net.core.somaxconn = 8192
    
net.core.rmem_max = 33554432
    
net.core.wmem_max = 33554432
    
net.core.optmem_max = 65536
    

    
# --- 3. 全局 TCP 内存池 (3G 内存精调版) ---
    
# 防止并发激增引发系统级 OOM，上限约控制在 614MB
    
net.ipv4.tcp_mem = 78643 117964 157286
    

    
# --- 4. BBRv3 核心引擎配置 ---
    
net.core.default_qdisc = fq
    
net.ipv4.tcp_congestion_control = bbr
    

    
# --- 5. BDP 动态视窗 (匹配 100M 带宽与 150ms 延迟) ---
    
net.ipv4.tcp_rmem = 4096 524288 33554432
    
net.ipv4.tcp_wmem = 4096 524288 33554432
    

    
# --- 6. 丢包/乱序自适应 (交由 BBRv3 与 RACK 处理) ---
    
net.ipv4.tcp_ecn = 1
    
net.ipv4.tcp_reordering = 3
    
net.ipv4.tcp_max_reordering = 300
    
net.ipv4.tcp_frto = 2
    
net.ipv4.tcp_sack = 1
    
net.ipv4.tcp_dsack = 1
    
net.ipv4.tcp_rfc1337 = 1
    

    
# --- 7. 连接状态与控制 ---
    
net.ipv4.tcp_max_tw_buckets = 65536
    
net.ipv4.tcp_max_syn_backlog = 8192
    
net.ipv4.tcp_syncookies = 1
    
# 禁用空闲后的慢启动，维持长连接的拥塞窗口大小
    
net.ipv4.tcp_slow_start_after_idle = 0
    
# BBR 系列极佳的起跑线控制，降低 Bufferbloat
    
net.ipv4.tcp_notsent_lowat = 16384
    
# 开启 TFO (客户端+服务端)，缩减握手 RTT 时间
    
net.ipv4.tcp_fastopen = 3
    

    
# --- 8. 路由转发、Anycast 与 NAT 追踪 (网关与容器核心) ---
    
# 开启 IP 转发
    
net.ipv4.ip_forward = 1
    
net.ipv6.conf.all.forwarding = 1
    
# 开启松散逆向路径过滤，兼容 Anycast 非对称路由
    
net.ipv4.conf.default.rp_filter = 2
    
net.ipv4.conf.all.rp_filter = 2
    
# 扩容连接跟踪表，防止 NAT 打满导致 Drop
    
net.netfilter.nf_conntrack_max = 1048576
    
# 缩短已建立连接的超时时间，加速释放闲置内存
    
net.netfilter.nf_conntrack_tcp_timeout_established = 3600
  • mic568 07-06 15:38
    2楼

    这个机 调优很有必要的 昨天看到有位佬说的 bbr fq 效果立竿见影，今天早上又按楼主的帖子设定了 mtu 和 bbr 缓存 现在有个小问题开网页会停顿一下然后嗖的一下就打开了 总体丢包 速度明显比之前好，

    tcp_slow_start_after_idle = 1 gpt 建议我改成 0


    tcp_fastopen = 1 建议我改成 3 ？有效果吗？

  • tof 楼主 07-06 15:44
    3楼

    @mic568 #2 我还没仔细检查这个参数 不过都试试呗 主要的搞对应该问题不大

  • qq7119 07-06 15:44
    4楼

    @tof #1


    建议弄成一键调优

  • tof 楼主 07-06 17:23
    5楼

    @mic568 #2 看了下gpt是对的 我的上一个设置是这样 https://www.nodeseek.com/post-784040-1

    准备一会更新下

* 帖子来源NodeSeek
附近帖子
返回
飞读
随机推荐