日本东京VPS在国内访问场景里一直是个矛盾体——物理距离比香港远，但价格往往便宜不少。很多用户买回来发现白天延迟还行，一到晚高峰就卡得没法用。除了线路本身的质量问题，服务器系统层的TCP协议栈配置不当，也是导致带宽跑不满、延迟波动大的重要原因。

　　日本东京VPS企业级系统调优方案：BBR拥塞控制 + fq队列调度 + 内核缓冲区精细化调整。每一步都讲清楚为什么这么做、怎么做、怎么验证。

　　一、先搞清楚：为什么东京VPS需要这套调优

　　日本到中国的网络路径有几个特点，直接决定了默认的Linux配置在这里表现不佳：

　　跨境链路存在天然丢包。东京到上海、北京的物理距离决定了RTT在40-80ms之间，晚高峰时段国际出口拥堵，丢包率可能从白天的0.5%飙到3%-10%。传统的Cubic拥塞控制算法把丢包当作拥堵信号，一旦检测到丢包就大幅降速，结果就是带宽利用率极低。

　　带宽延迟积(BDP)不小。以100Mbps带宽、60ms RTT计算，BDP = 100Mbps ÷ 8 × 0.06s ≈ 750KB。如果TCP缓冲区只有默认的几MB，在长肥管道(高带宽×高延迟)上根本跑不满。

　　日本运营商对中国流量的路由策略不稳定。NTT线路经常绕道美国西海岸再回中国，导致延迟翻倍。这种绕路进一步增大了RTT，对缓冲区的要求更高。

　　这套调优的目标很明确：让服务器在跨境链路上尽可能榨出可用带宽，同时降低延迟抖动。

　　二、开启BBR + fq队列

　　BBR是Google开发的拥塞控制算法，核心思路是不再依赖丢包判断拥堵，而是主动测量网络路径的瓶颈带宽和往返延迟。在存在丢包的跨境链路上，BBR的优势非常明显——它不会因为少量丢包就大幅降速，而是持续探测可用带宽。

　　fq(Fair Queue)是配套的队列调度算法，BBR官方推荐搭配使用。fq让数据包按流公平排队，避免单个大流量连接把队列占满导致其他连接延迟飙升。

　　1. 检查内核版本

uname -r

　　如果输出类似 5.4.0-xxx 或 5.15.0-xxx，继续往下。如果内核版本低于4.9(常见于CentOS 7)，需要先升级内核。

　　2. 启用BBR和fq

　　编辑 /etc/sysctl.conf，追加两行：

echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf

　　然后加载配置：

sysctl -p

　　3. 验证是否生效

sysctl net.ipv4.tcp_congestion_control
lsmod | grep bbr

　　第一条命令应该输出 net.ipv4.tcp_congestion_control = bbr。第二条命令如果看到 tcp_bbr 模块，说明BBR已经加载。

　　注意：部分系统可能需要先加载模块才能启用。如果 lsmod 没有输出，执行：

modprobe tcp_bbr

　　三、内核缓冲区精细化调优

　　BBR负责“怎么发”，缓冲区负责“能发多少”。如果缓冲区太小，BBR即使探测到了可用带宽，也无法把足够的数据塞进管道里。

　　理解三个关键参数

　　net.ipv4.tcp_rmem 和 net.ipv4.tcp_wmem 各接受三个值：最小值、默认值、最大值。

　　以默认的 tcp_rmem = 4096 87380 6291456 为例：

　　4096：接收缓冲区的最小值，系统内存紧张时也不会低于这个值

　　87380：默认值，在无压力情况下缓冲区可以增长到这个值

　　6291456：最大值，这是自动调优的上限。问题就在这里——6MB对于跨境高BDP链路来说往往不够

　　计算你需要多大的缓冲区

　　缓冲区最大值应该至少等于BDP，建议设为BDP的2-3倍。

　　东京到中国典型场景：

　　100Mbps带宽、60ms RTT：BDP ≈ 750KB，最大值建议 2-8MB

　　500Mbps带宽、60ms RTT：BDP ≈ 3.75MB，最大值建议 8-16MB

　　1Gbps带宽、60ms RTT：BDP ≈ 7.5MB，最大值建议 16-32MB

　　推荐的企业级配置

　　对于大多数东京VPS场景(100Mbps-1Gbps端口，RTT 40-80ms)，以下配置经过生产环境验证：

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

　　参数解释：

• rmem_max/wmem_max = 16777216(16MB)：单个Socket缓冲区的硬上限
• tcp_rmem 最大值设为16MB：接收缓冲区可增长到16MB
• tcp_wmem 最大值设为16MB：发送缓冲区可增长到16MB
• 如果VPS内存较小(1GB以下)，适当降低最大值，比如设为8MB，避免单个连接占用过多内存。

　　连接队列调优

　　高并发场景下，连接队列满了会导致新连接被丢弃或延迟增加：

net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.core.netdev_max_backlog = 32768

• somaxconn：已完成三次握手的连接队列最大值
• tcp_max_syn_backlog：半连接队列(SYN队列)最大值
• netdev_max_backlog：网卡接收数据包的队列长度

　　其他值得调整的参数

net.ipv4.tcp_fastopen = 3
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_max_tw_buckets = 65536
net.ipv4.ip_local_port_range = 1024 65535

• tcp_fastopen = 3：启用TCP Fast Open，允许在SYN包中携带数据，减少一次往返
• tcp_tw_reuse = 1：允许复用TIME_WAIT状态的连接，缓解端口耗尽
• ip_local_port_range：扩大本地端口范围，支持更多出站连接

　　四、完整配置流程

　　把所有配置整合到一个文件中，方便管理和复用。

　　1. 创建配置文件

sudo nano /etc/sysctl.d/99-tcp-tuning.conf

　　粘贴以下内容：

# ========== BBR + fq ==========
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

# ========== TCP缓冲区 ==========
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# ========== 连接队列 ==========
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.core.netdev_max_backlog = 32768

# ========== 其他优化 ==========
net.ipv4.tcp_fastopen = 3
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_max_tw_buckets = 65536
net.ipv4.ip_local_port_range = 1024 65535

# ========== 文件描述符 ==========
fs.file-max = 1000000

　　2. 应用配置

sudo sysctl -p /etc/sysctl.d/99-tcp-tuning.conf

　　3. 验证配置

sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc
sysctl net.ipv4.tcp_rmem
sysctl net.ipv4.tcp_wmem

　　确认输出与配置一致。

　　五、调优效果验证

　　配置完成后，用实际测试验证效果。

　　基础测试：iperf3

　　在另一台机器上运行 iperf3 -s，在东京VPS上执行：

iperf3 -c 对端IP -P 4 -t 30

　　重点关注 Bitrate(吞吐量)和 Retr(重传次数)。调优后吞吐量应该有明显提升，尤其是晚高峰时段。

　　延迟测试

mtr -n -c 100 -r 目标IP

　　观察每一跳的延迟和丢包。如果中间节点丢包但最后一跳正常，说明是ICMP限速，不影响实际传输。

　　实际体验

　　SSH操作是否更流畅、网站后台响应是否更快、文件下载速度是否稳定——这些主观感受比跑分数据更有参考价值。

　　六、一个必须知道的局限性

　　这套系统层调优能解决的是“服务器自己没有发挥出应有能力”的问题。如果调优后带宽依然跑不满，问题可能出在：

　　1. 商家侧QoS限速：测速开始时快、迅速降到某个数值并稳定，这是典型的动态限速

　　2. 线路本身质量差：普通NTT线路晚高峰丢包严重，BBR也救不了

　　3. CPU瓶颈：1核VPS跑大流量时，网络中断处理本身就会吃掉大量CPU时间

　　系统调优是“把服务器该做的事做好”，但它改变不了线路的物理质量和商家的商业策略。如果调优后无明显改善，换一家走软银或CN2 GIA线路的东京VPS，比继续折腾内核参数更划算。