引子：多线出口带来的内核参数沼泽

BGP多线主机的卖点是低延时、高可用，但真正上手跑业务时，内核的默认参数恰恰是为单线路环境设计的。新手常遇到客户端间歇性连不上、丢包率莫名升高、带宽跑不满——大部分锅都在以下5个内核参数上。本文不讲废话，直接给代码和排错思路。

坑1：路由不对称导致TCP连接被内核“自杀”

现象

服务器通过BGP多线同时连电信/联通/移动，客户端回包的源IP可能与服务器发送时用的源IP不一致（比如服务器用电信出口，客户端走联通回包）。Linux内核默认的rp_filter（反向路径过滤）在严格模式（1）下会直接丢弃这种非对称包，导致SYN-ACK发出去但客户端收不到，建连失败。

排查

# 查看当前rp_filter值（0=关闭，1=严格，2=松散）
sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.eth0.rp_filter

如果返回1，且你的业务存在多出口多路径，请立即调整为松散模式或关闭。

解决方案

# 临时生效（松散模式）
sysctl -w net.ipv4.conf.all.rp_filter=2
# 持久化写入 /etc/sysctl.conf
net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.default.rp_filter = 2

注意：完全关闭(=0)会暴露反射攻击风险，建议只设松散模式=2，并配合精确的策略路由。例如，在轻云互联BGP多线主机上，我习惯将每个物理网卡绑定独立的路由表，再通过ip rule指定源路由，配合rp_filter松散模式，确保无错。

坑2：连接跟踪表(conntrack)爆满，新连接被“饿死”

现象

BGP多线意味着大量客户端经过不同运营商访问，conntrack表条目数可能轻松突破几十万。默认值nf_conntrack_max通常只有65536，超过后内核直接丢弃新连接（包括UDP和TCP）。很多新手用dmesg看到nf_conntrack: table full, dropping packet却不知道根因。

排查

# 查看当前连接数
cat /proc/sys/net/netfilter/nf_conntrack_count
# 查看最大限制
cat /proc/sys/net/netfilter/nf_conntrack_max

调优

# 根据内存大小调整（建议为内存的1/8，单位KB）
echo 2097152 > /proc/sys/net/netfilter/nf_conntrack_max
# 同时增大hash表大小（需在模块加载时指定，修改 /etc/modprobe.d/conntrack.conf）
options nf_conntrack hashsize=524288

此外，关闭不必要的conntrack模块：nf_conntrack_sip、nf_conntrack_amanda等很少用，却消耗CPU。在BGP多线场景下，我习惯只用基础模块：

# 编辑 /etc/modprobe.d/blacklist-nf.conf
blacklist nf_conntrack_sip
blacklist nf_conntrack_h323
# 重启后生效，或手动 rmmod
modprobe -r nf_conntrack_sip

坑3：BBR拥塞控制在多运营商环境下的“假死亡”

现象

BBR在单一低延迟链路上表现优异，但BGP多线主机的出口可能同时经过高延迟（卫星/跨国）和低延迟（本地）链路。BBR的带宽探测阶段会被跨运营商的路由抖动打断，导致发送窗口频繁波动，实际吞吐还不如CUBIC。

排错手段

# 查看当前拥塞控制算法
sysctl net.ipv4.tcp_congestion_control
# 查看系统支持的算法
sysctl net.ipv4.tcp_available_congestion_control

推荐配置

• 对延迟敏感的实时小包业务（如WebSocket、游戏）：使用vegas或hybla（尤其适合卫星链路）。
• 对吞吐敏感的CDN/下载：用bbr配合tcp_rmem手动调大，避免自动缩放延迟。

# 临时切换
sysctl -w net.ipv4.tcp_congestion_control=vegas
# 持久化
echo 'net.ipv4.tcp_congestion_control = vegas' >> /etc/sysctl.conf

如果使用BBR，必须同时调大socket缓冲区的天花板，否则高延迟下带宽上不去：

# 允许最大接收/发送缓冲区为16MB
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216
sysctl -w net.ipv4.tcp_rmem='4096 131072 16777216'
sysctl -w net.ipv4.tcp_wmem='4096 65536 16777216'

坑4：tcp_tw_reuse和tcp_tw_recycle在NAT环境下的致命错误

现象

很多教程喜欢教人开启tcp_tw_reuse=1和tcp_tw_recycle=1来回收TIME_WAIT连接，但在BGP多线主机背后常有负载均衡或NAT设备。启用tcp_tw_recycle后，内核会通过对端IP的时间戳校验，当不同客户端的NAT出口不同时（时间戳不一致），会直接丢弃合法SYN包，导致部分用户无法连接。

原则

在BGP多线场景下，永远不要启用tcp_tw_recycle（自Linux 4.12起已废弃）。tcp_tw_reuse在客户端使用时安全，但服务端建议配合tcp_timestamps谨慎使用。

正确做法

# 关闭这两个参数（确认当前值）
sysctl net.ipv4.tcp_tw_reuse
sysctl net.ipv4.tcp_tw_recycle
# 如果开启，改为0，并写入sysctl.conf
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_tw_recycle = 0

替代方案：使用tcp_fastopen或调整tcp_max_tw_buckets来限制TIME_WAIT总数，而不是回收。

坑5：TCP RTO初始值过大导致慢启动“慢半拍”

现象

BGP多线主机可能接入不同运营商的链路，延迟差异巨大（如电信5ms，移动50ms）。内核默认的TCP初始RTO（超时重传时间）为1秒，若链路上存在少量丢包，重传等待时间过长加剧用户体验恶化。对于电信/联通等低延迟链路，可以适当降低RTO最小值。

调整

# 查看当前初始RTO（毫秒）
cat /proc/sys/net/ipv4/tcp_rto_min
# 设置最小值200ms（默认200，某些内核已支持动态调整）
sysctl -w net.ipv4.tcp_rto_min=200
# 另一个相关参数：减少初始RTO（默认3000ms？其实内核4.x后已改用rto_min）
# 使用 fq 调度 + pacing 也能改善
echo 'fq' > /proc/sys/net/core/default_qdisc

更直接的方法：启用TCP小包微突发优化，增加tcp_slow_start_after_idle=0避免空闲后回到慢启动：

sysctl -w net.ipv4.tcp_slow_start_after_idle=0

总结：一次性给出一份配置模板

以下是我在轻云互联BGP多线主机上验证过的稳定配置（/etc/sysctl.d/99-bgp-optimization.conf）：

# 路由不对称
net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.default.rp_filter = 2

# 连接跟踪
net.netfilter.nf_conntrack_max = 2097152
net.netfilter.nf_conntrack_tcp_timeout_established = 432000

# TCP缓冲区（按16MB天花板调）
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 131072 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# 拥塞控制（根据业务选一个）
net.ipv4.tcp_congestion_control = hybla   # 或 vegas / bbr

# 关闭危险回收
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_tw_recycle = 0

# 减少重传等待
net.ipv4.tcp_slow_start_after_idle = 0
net.core.default_qdisc = fq

# 开启TCP时间戳（配合bbr需要）
net.ipv4.tcp_timestamps = 1

执行sysctl --system加载。建议先在非生产环境验证，特别是rp_filter和conntrack的改动。BGP多线主机的内核调优没有银弹，唯一真理是：理解每个参数的语义，再用你的业务流量验证。