3x-ui的多用户不是在一个单独的用户管理页面里统一操作的，而是在每个入站节点下面单独管理。如果你要给同一个节点分配多个用户，进入面板后点左侧的入站列表，找到对应的节点，点那一行最右边的用户图标就能进入这个节点的用户列表。

刚装完面板的时候，每个入站节点默认只有一个用户。点添加用户会弹出一个表单，里面有几个字段需要填。

客户端名字默认是一串随机字符，比如 a1b2c3d4，这个字段可以自己改成好认的名字，比如设备名或者用途。改不改都不影响节点正常连接，只是方便自己管理。用户多了之后，列表里一眼就能看出来哪个是自己手机在用、哪个是给朋友开的，不用对着一堆随机字符猜。

UUID 那一栏默认是自动生成的，一般不需要动，每个用户的 UUID 都不一样，这也是区分不同用户流量的依据。

流量限制那栏填 GB 数字，比如填 50 就是限制这个用户总共能用 50GB。默认是空的，也就是不限流量。如果要给朋友开节点但不想让他用太多，在这里填个数字就行。流量超限之后用户不会立刻断线，而是在面板的用户列表里显示超限状态，这时候这个用户的连接就无法使用了，需要你手动在面板里重置流量或者调整限额，才能恢复正常。

到期时间填日期格式，比如 2026-12-31，到了这个日期之后这个用户自动失效。默认也是空的，也就是永不过期。给朋友开节点的时候可以设个到期时间，省得以后忘了还在跑。

添加完之后回到用户列表，每个用户那一行右边有一个二维码图标，点开可以看到这个用户专属的订阅链接，每个用户的链接是独立的，互不影响。把链接直接发给对方就能用，不需要对方扫码，复制链接粘贴到客户端的订阅地址里导入就行。如果对方用的是手机，扫二维码也可以，两种方式都支持。

需要注意的是，每个用户的链接只包含这一个用户的配置，不会把同一个入站下其他用户的信息带进去。所以如果你给三个朋友各开了一个用户，发给他们的是三条不同的链接，互相之间看不到对方的配置。

如果要删掉某个用户，直接在列表里点那一行的删除按钮，不会影响同一个入站下的其他用户，节点本身也不需要重启，删完立刻生效。删掉之后对方的链接就直接失效了，不需要额外操作。

用户多了之后有几个管理习惯比较省事：名字按照用途或者对象来命名，比如 phone、laptop、friend-a 这种，比随机字符好找很多。流量和到期时间按需要设，不是每个用户都要限制，自己用的一般不用管，给别人开的建议设个到期时间。定期去用户列表看一眼，超限的、过期的及时清理，面板不会自动删除这些用户，需要手动处理。

如果同一台服务器要同时跑多个协议，比如 VLESS Reality 和 Hysteria2 分开两个入站，每个入站下面可以各自独立管理用户，互相不影响。不同入站的用户链接格式不一样，不能混用。

面板安装和基本配置可以参考这篇：3x-ui安装：MHSanaei版官方脚本与面板配置

从网上下载一个ISO镜像或者软件包，尤其是从镜像站、种子网络这类不完全受控的渠道拿到的文件，装到系统里之前多一步验证，能避免装了个被人动过手脚的版本。很多教程只教到sha256sum这一步就停了，其实这只完成了验证工作的一半。

sha256sum验证的是"完整"，不是"真实"

1

sha256sum 下载的文件名

跑出来的这一串哈希值，如果跟官方公布的校验值对上了，说明这个文件在传输过程中没有损坏或者被篡改——但这里有个容易被忽略的漏洞：如果攻击者连官方公布的校验值本身也一起篡改了（比如你是从一个被劫持的镜像站同时拿到了文件和它对应的SHA256SUMS文件），两者对得上号，你验证得再仔细也是白搭，因为参照物本身就是假的。单纯的哈希校验，验证的是"文件有没有在传输中损坏"，回答不了"这个文件到底是不是官方发布的原版"这个更关键的问题。

GPG签名验证，才是真正在确认"来源"

想同时验证完整性和真实性，得靠GPG签名这一层。以Ubuntu镜像为例，官方在发布ISO的同时，还会提供一份对应的.gpg签名文件，这份签名是用官方私钥对校验文件本身签的名，只有真正的官方才能生成这个签名。

先导入官方的公钥：

1

gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 官方公钥ID

再用这个公钥验证签名文件：

1

gpg --verify SHA256SUMS.gpg SHA256SUMS

看到Good signature from这行，说明这份校验文件确实是官方私钥签过名的，不是中途被人偷梁换柱换成假的。这一步验证通过之后，再拿这份可信的校验文件去比对你下载的实际文件：

1

sha256sum -c <(grep 你的文件名 SHA256SUMS)

两步叠加起来，才算是既确认了"文件没坏"，又确认了"文件确实来自官方"，单独任何一步都不能完全说明问题。

平时这么严格的验证，什么时候真正用得上

日常从大厂官方渠道装个常规软件包，被篡改的风险本来就不高，没必要每次都走这一整套流程。但遇到这几种场景，多花两分钟验证一下很值——从BT种子网络下载的镜像文件、从个人维护的第三方软件源添加的包、或者干脆是从来源不太确定的镜像站下载的东西。

一个容易忽略的细节：公钥本身也得从可信渠道拿

验证流程里还有个环节容易被跳过——gpg --recv-keys这一步，是从密钥服务器拉取官方公钥，如果这个公钥本身就是假的（比如从一个不可信的地方手动导入了一个伪造的公钥），后面所有的验证步骤都会"验证成功"，但验证的是攻击者伪造的一整套签名体系，看着流程走完了，结果照样是假的。密钥服务器本身通常是分布式、多方维护的，比单一站点可信度更高，但如果条件允许，最好还是从软件官方网站直接确认一下公钥指纹（fingerprint）对不对得上，而不是盲目信任密钥服务器返回的第一个结果。

顺带一提

之前写Helium浏览器那篇提到过"只从官方GitHub下载，避免被篡改的安装包"，这条建议背后的具体操作方法，其实就是这篇讲的这一套——不管是给服务器装软件包，还是给手机装一个第三方浏览器APK，验证来源可信这件事的思路是通用的。如果是在排查服务器是否已经被入侵，类似的多方交叉验证思路，可以参考VPS被暴力破解怎么查有没有被入侵那篇。

Fail2ban装完，systemctl status fail2ban显示绿色的active (running)，看着一切正常，从此就不再管它，默认它一直在尽职尽责地拦截暴力破解。这个假设有风险——Fail2ban显示"运行正常"、甚至显示"已封禁某个IP"，都不代表它真的在起作用，一些常见的配置疏漏会让它变成一个只会报告好消息、实际什么都没拦住的摆设。

改了SSH端口，但没同步告诉Fail2ban

这是最容易被忽略、后果也最严重的一个坑。很多人图安全，把SSH默认端口从22改成别的数字，却忘了Fail2ban的对应规则里，action配置那一行写死了port=ssh（对应端口22）。攻击者其实是冲着你改过的新端口来的，Fail2ban监控日志确实检测到了暴力破解、确实执行了"封禁"动作，fail2ban-client status sshd看着显示封禁成功——但它实际下发的防火墙规则，拦的是22端口，跟攻击者真正在用的端口完全不搭边，等于什么都没拦住，只是自己心理上以为安全了。

改了SSH端口，记得同步改一下jail.local里对应规则的端口设置：

1
2
3
4

[sshd]
enabled = true
port = 你改过的实际端口号
logpath = /var/log/auth.log

系统时区变过，日志时间跟Fail2ban对不上

如果服务器中途调整过时区（或者之前排查过NTP同步问题动过手脚），日志里记录的时间戳如果跟Fail2ban自己感知的当前时间对不上，会导致它在判断"某个IP在规定时间窗口内失败了几次"这个逻辑上完全错乱，实际效果就是日志明明在报警，Fail2ban却始终判断"还没到触发阈值"，安静地什么都不做。这跟之前写的VPS的时间为什么会跑偏是同一类隐患的连锁反应——时间本身出问题，牵连的往往不只是日志时间戳好不好看，依赖时间判断逻辑的安全工具会跟着一起失灵。

封禁动作报告成功，防火墙规则却压根没插进去

还有一种更隐蔽的失效——fail2ban-client status sshd显示某个IP已经在封禁列表里，回头用iptables -L一查，对应的拦截链条根本不存在，日志里能翻到No chain/target/match by that name这类报错。这种情况下Fail2ban自己以为完成了任务，实际防火墙层面什么规则都没真正生效，攻击者畅通无阻。定期交叉验证一下两边的状态是否一致，比只看Fail2ban自己的汇报靠谱：

1
2

fail2ban-client status sshd
iptables -L -n | grep f2b

两边如果对不上号，说明封禁动作在防火墙这一层出了问题，需要单独排查。

验证Fail2ban到底有没有在正常读日志

不用干等着真实攻击发生才能验证，直接拿现有日志测一下正则匹配规则能不能正常识别：

1

fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf

如果匹配数量是0，问题可能出在日志格式跟预设的正则对不上——这种情况在用了Docker之类会给日志额外插入字段的环境下尤其常见，日志格式跟原生系统的默认格式有出入，Fail2ban的默认过滤规则可能压根认不出来。

顺带一提

这种"工具装了、开关打开了、看着一切正常，实际却完全没起作用"的情况，跟之前写的ulimit设置了却不生效是同一种性质的陷阱——配置本身可能一个字都没写错，但环境或者关联的另一项设置对不上，整套东西就变成了摆设。装完安全工具，花两分钟做一次真实验证，比事后翻日志才发现从来没生效过要踏实得多。

用手机Termux连着VPS跑一个耗时的任务，切个微信回来一看，会话断了，任务也没了，跟没跑过一样。这不是Termux不稳定，是安卓系统的省电机制在暗中动手——手机为了省电，会主动清理它认为"不重要"的后台进程，Termux作为一个终端应用，很容易被系统划进这个清理名单。

第一层防护：唤醒锁+电池白名单

最基础的两步，跑长任务之前先做好：

在Termux菜单里点"Acquire Wakelock"，或者直接敲命令：

1

termux-wake-lock

这个操作能阻止CPU进入深度睡眠，任务跑完之后记得释放：

1

termux-wake-unlock

同时去手机系统设置里，把Termux的电池优化策略改成"不受限制"（不同手机厂商叫法不一样，可能是"无限制""允许后台活动"之类），避免系统按默认的激进策略清理它。

第二层防护：把任务放进tmux，而不是直接跑在主会话里

单纯开着wake-lock还不够稳妥，配合之前写过的SSH断连处理方法，把任务放进tmux会话里跑，就算Termux本身被系统重启或者意外重开，只要底层进程没被真正杀死，重新连回去还能接上：

1

tmux new -s 任务名

安卓12/13上，做完前两步可能还是不够

这是最容易被忽略、也最让人困惑的一层——安卓12和13新增了一个叫"Phantom Process Killer"（幽灵进程终结者）的机制，就算唤醒锁开着、电池优化也关掉了，这套新机制依然可能把你的后台会话干掉，因为它管的是另一套判定逻辑，不完全受传统的电池优化设置约束。

遇到这种情况，需要通过ADB命令单独放宽这个限制（需要电脑连接手机执行，或者用Termux本身的ADB无线调试功能）：

1

adb shell "/system/bin/device_config put activity_manager max_phantom_processes 2147483647"

这条命令把系统允许的"幽灵进程"数量上限调到接近无限大，绕开这套新的杀后台机制。

一个容易被忽视的反向陷阱

设置好前面这些之后，千万别手动开启手机的"省电模式"——这个模式会直接覆盖掉唤醒锁的效果，不管你之前设置得多仔细，一旦手动打开省电模式，后台任务照样立刻被杀，等于前功尽弃。

如果想让tmux会话在手机重启之后也能自动恢复，可以研究一下tmux-resurrect这个插件，能把会话状态保存下来，重启后自动还原。

顺带一提

这种"系统默认倾向于清理你没有特别保护的东西"的思路，跟Linux里kill -9都杀不死一个进程那篇讲的其实是完全相反的情况——一个是"太容易被杀掉"，一个是"怎么杀都杀不掉"，两种极端背后都是系统在某种机制下的默认行为，了解清楚各自的逻辑，才知道该往哪个方向去应对。如果手机上除了Termux还跑着Mdpings这类需要常驻后台的探针App，同样的保活思路也适用，都得先过电池优化这一关。

VPS本身IPv6配置得妥妥当当，ping -6一测宿主机畅通无阻，装进容器里的服务却怎么都连不上IPv6，docker exec进去一试，IPv6网络对这个容器来说压根不存在。折腾半天以为是容器内部网络设置有问题，其实Docker默认根本不会把宿主机的IPv6能力传给容器，这是设计上的默认行为，不是哪里配错了。

Docker压根没把IPv6当默认选项

Docker对IPv6的支持长期不如IPv4积极，容器网络默认走的是私有的IPv4段，宿主机有没有IPv6跟容器能不能用IPv6，是两件完全不搭界的事。想让容器拿到IPv6能力，得手动改Docker的配置文件：

1

vi /etc/docker/daemon.json

加上这两项：

1
2
3
4

{
  "ipv6": true,
  "fixed-cidr-v6": "fd00:db8:1::/64"
}

fixed-cidr-v6给的是一个私有IPv6网段，容器之间用这个网段互相通信；fd00::/8这类前缀是IPv6里对应IPv4私有地址（10.0.0.0/8那种）的等价物，专门留给内网场景用，照抄这个格式就行，不用自己纠结换成别的网段。

改完重启Docker服务让配置生效：

1

systemctl restart docker

确认有没有真的生效

1

docker network inspect bridge

看输出里EnableIPv6这一项是不是true，IPAM.Config里有没有出现你刚才配的那个IPv6网段。这一步能省掉后面很多冤枉排查——如果这里显示没生效，再怎么折腾容器内部网络设置都是白费功夫。

光配置daemon.json，可能还不够

如果宿主机的网关分配的是私网IPv6（不是公网直连），上面这套配置一般能直接生效；但如果宿主机拿到的是公网IPv6网关，情况会复杂一些，理论上还得配合iptables（准确说是IPv6对应的ip6tables）做地址映射才能真正打通，光改daemon.json不一定够用，具体取决于VPS服务商分配IPv6的方式。

确认改动生效后，实际测试一下：

1

docker run --network=bridge --rm -it busybox ping -6 -c4 google.com

只是临时用一下，也可以走host网络模式

如果不想动全局的Docker配置，只是某个容器临时需要用IPv6，还有个更简单的旁路方案——用host网络模式跑这个容器，直接借用宿主机自己的网络协议栈，宿主机能访问IPv6，容器立刻就能访问，不需要额外配置：

1

docker run --network=host 镜像名

缺点是host模式下容器和宿主机共用同一套网络命名空间，端口映射这些跟bridge模式的逻辑不一样，适合临时验证或者单容器场景，如果是多容器长期跑的生产环境，还是建议老老实实按上面的方式把daemon.json配好，更规范也更好维护。

顺带一提

这种"宿主机能力齐全，但容器/子系统默认不继承"的情况，跟之前写的VPS重启后Docker容器为什么没有自动启动是同一个脾气——Docker很多行为默认都偏保守，不会自作主张帮你把宿主机的能力透传进去，重启策略是这样，IPv6支持也是这样，新装的服务多留意一下默认值，别想当然。如果这台VPS本身的IPv6配置就有问题（不只是Docker层面），可以先看VPS防火墙规则设置了，IPv6那边却像没设一样那篇，排查一下宿主机这一层的IPv6是不是真的健康，再往Docker这一层深入。

辛苦用iptables把防火墙规则配得严严实实，只放行指定端口、指定IP，自我感觉安全性拉满，结果压根没意识到——这些规则从头到尾只管住了IPv4这一半，IPv6完全是另一套独立体系，你写的东西对它一个字都不生效。

iptables和IPv6，压根不是一回事

iptables工作在AF_INET这个协议族上，专门为IPv4设计，对IPv6流量完全没有感知能力。IPv6走的是独立协议栈路径，得靠专门的ip6tables来管，两者共享底层netfilter框架，但分别注册、分别生效，语法长得几乎一样，管的却是两拨完全不搭界的流量。只用iptables配规则、以为IPv6也顺带被保护了，是个非常容易踩、后果却不轻的误区。

配置IPv6对应规则，思路照搬IPv4那一套，工具换成ip6tables就行：

1
2
3

ip6tables -A INPUT -p tcp --dport 22 -j ACCEPT
ip6tables -A INPUT -p tcp --dport 80 -j ACCEPT
ip6tables-save > /etc/iptables/rules.v6

更让人后背发凉的反过来的情况

如果说"规则没生效"只是让你以为自己被保护了、实际没有，那还只是白忙活一场；更麻烦的是不少发行版的ip6tables默认策略，压根不是"拒绝"，而是"完全放行"（ACCEPT）：

1

ip6tables -L INPUT

如果看到默认策略显示ACCEPT，意味着从这台VPS装好系统那一刻起，IPv6方向的流量就一直毫无过滤地大门敞开，而你可能从来没有主动碰过ip6tables这个东西，甚至根本不知道它的存在——不是"配置失误留了漏洞"，是从起点开始就没设防。

ICMPv6不能照搬IPv4的思路一刀切

排查安全时另一个常见冲动是"干脆把ICMPv6也全部堵死，图省事"。这个思路在IPv4上问题不大，但在IPv6里行不通——ICMPv6承担的职责比IPv4的ICMP重要得多，邻居发现（NDP，相当于IPv6版本的ARP）、路由通告（地址自动配置全靠它）、路径MTU发现，全部依赖它正常工作。一刀切全部拦掉，轻则地址自动配置失败，重则触发之前写过的PMTU黑洞问题——同样是"连接能建立，数据传不动"的诡异症状，追根溯源发现是自己手贱把ICMPv6堵死了。

用UFW能省心不少

如果嫌iptables和ip6tables两套分开管理麻烦，UFW（Uncomplicated Firewall）在/etc/default/ufw里把IPV6设成yes之后，会自动帮你同步维护IPv6对应的规则，不用两边分别敲命令，出这类"顾此失彼"漏洞的概率也小得多。

怎么确认自己中招没有

从外部找一台能访问IPv6的设备，实测一下端口连通性，同时对照本机监听情况：

1
2
3
4
5

# 从外部测试
nc -zv 服务器IPv6地址 22

# 本机确认监听状态
netstat -tulnp | grep :22

如果IPv4访问一切正常、限制生效，IPv6那边却怎么连都能连上（哪怕是本该被拦住的端口），基本可以确定就是这个坑。

顺带一提

这种"IPv6单独游离在常规配置体系之外"的情况，跟之前写的改了disable_ipv6，IPv6却没被真正关掉是同一大类问题——很多人管理VPS习惯性只按IPv4思路走一遍，IPv6要么被漏掉、要么行为跟预期完全不一样。如果是排查安全问题时发现了类似的IPv6漏防情况，建议连着VPS被暴力破解怎么查有没有被入侵那篇一起走一遍，确认漏洞暴露的这段时间没被人趁虚而入。

写了个脚本，手动bash script.sh跑一遍好好的，扔进crontab设置成定时任务，到点却什么反应都没有，日志里也不报错，就是安安静静地什么都没发生，排查起来比报错还让人摸不着头脑。

手动跑和定时跑，压根不是同一个环境

这是最常见也最容易被忽略的根源——crontab执行任务时用的环境变量，跟你SSH登录之后手动跑命令用的环境变量，是两套完全不同的东西。你平时登录之后能直接敲node、python3、docker这些命令，靠的是~/.bashrc、/etc/profile这些文件里定义好的PATH，把这些工具所在的目录加了进去。但cron执行任务的时候，根本不会去读取这些登录相关的配置文件，它用的是一套非常精简的默认环境，PATH通常只有/usr/bin:/bin这么两个目录，你手动装的那些工具，如果装在/usr/local/bin或者别的自定义路径下，在cron的世界里压根就"不存在"，脚本一执行到那条命令，直接报"command not found"，只不过这个报错默认没地方看，你压根不知道它失败了。

一个简单的验证办法

不确定是不是这个原因，加一条临时任务，把cron实际能看到的环境变量导出来看看：

1

* * * * * env > /tmp/cron_env.log

等一分钟之后打开这个文件，对比一下跟你正常登录之后执行env看到的结果，PATH这一项基本一眼就能看出差在哪。

怎么解决

最省事、也最推荐的做法是脚本里所有命令都用绝对路径，不依赖PATH去帮你找：

1

/usr/local/bin/node /home/user/script.js

而不是简简单单写node script.js寄希望于PATH自动找到它。找命令的绝对路径，用which查一下就行：

1

which node

如果不想每条命令都改成绝对路径，也可以在脚本开头显式声明PATH，或者干脆把需要的环境变量手动export一遍：

1

export PATH=$PATH:/usr/local/bin

别忘了这几个更基础的排查点

除了PATH这个最典型的坑，还有几个同样常见、优先级甚至更靠前的问题，一并确认一下：

• crond这个服务本身有没有在跑：systemctl status crond（或者cron，看发行版），服务都没启动，配再多定时任务也是白搭
• 脚本有没有执行权限：chmod +x script.sh，缺了这一步，手动bash执行能绕过去，cron直接调用可能会失败
• 时间字段有没有写错：crontab的五个时间字段格式很容易手滑写错（比如把"每2小时"错写成"每小时的第2分钟"），跟命令本身没关系，纯粹是排班表写错了

顺带查日志

想知道任务到底执行了没有、失败在哪一步，给命令末尾加上日志重定向，比干等着猜靠谱得多：

1

* * * * * /path/to/script.sh >> /tmp/script.log 2>&1

顺带一提

这种"手动跑正常，交给系统自动执行就失灵"的情况，跟之前写的VPS改了Nginx配置，网站却还是老样子其实是同一类思路——不管是Nginx的配置生效，还是cron的执行环境，自动化的那一层跟你手动操作时的环境、状态都不完全一样，出问题的时候别光盯着命令本身对不对，环境差异往往才是真正的元凶。

改好nginx.conf，保存、刷新浏览器，页面纹丝不动，跟没改过一模一样。这种情况排查起来容易陷入死循环——反复检查配置文件哪里写错了，其实配置文件本身可能一个字都没错，问题出在别的环节。

第一层：Nginx不会自己发现配置变了

Nginx跟很多现代化服务不一样，它不会实时监控配置文件有没有被修改，改完文件之后，得手动发送一个信号告诉它"该重新读配置了"：

1

nginx -s reload

不发这个信号，Nginx会一直按内存里旧的那份配置继续跑，不管文件本身改成什么样。这是最常见、也是最容易被忽略的第一层原因。

第二层：reload了，但语法错误让它悄悄回滚

如果确实执行过reload，但配置文件里有语法错误，Nginx有个挺贴心也挺容易让人摸不着头脑的保护机制——先检查新配置的语法，发现有问题，直接放弃这次加载，继续用上一次能正常跑的旧配置顶着，服务不会中断，但你的改动压根没生效，而且不会有特别显眼的提示。改之前养成习惯，先测试语法：

1

nginx -t

看到syntax is ok和test is successful两行都出现，再执行reload，能避免这个坑。

第三层：不是所有改动reload都管用

大部分配置调整reload就够了，但有几种情况例外。如果改的是listen指令里监听的IP地址（不只是端口），部分版本下光reload可能不完全生效，得用完整重启：

1

systemctl restart nginx

还有个更隐蔽的情况——如果upstream配置的后端地址写的是域名而不是IP，域名对应的IP如果变了，reload并不会重新解析这个域名拿到新IP，因为DNS解析结果在Nginx内部是有缓存的，这种情况同样得靠完整重启才能刷新。

第四层：服务端真的没问题，是浏览器在使唤你

前面三层都排除了，服务端配置也确认生效了，网页看着还是没变化，这时候问题可能压根不在服务器这边——浏览器把旧版本的页面缓存住了，尤其是CSS、JS这类静态资源，浏览器默认会缓存很长时间。强制刷新（Ctrl+Shift+R或者手机端清一下浏览器缓存）通常就能解决，或者干脆换个无痕窗口访问确认。

一套排查顺序

遇到这种情况，按这个顺序过一遍，基本能定位到问题出在哪一层：先确认执行过reload；再用nginx -t确认配置语法本身没错、且reload真的成功应用了；如果改的是监听地址或者upstream域名这类特殊指令，直接换成restart更保险；最后如果服务端一切正常，浏览器强制刷新排除缓存干扰。

顺带一提

这种"配置文件确实改了，但正在运行的进程压根不知道"的情况，跟之前写的ulimit设置了却不生效是同一类问题的另一个变种——运行中的进程不会主动感知配置文件的变化，改完之后总得有个明确的动作（reload、restart，或者给systemd服务单独配置）去告诉它"该更新了"，这条规律在很多Linux服务上都成立，不只是Nginx。

VPS上跑date一看，时间跟手机差了好几分钟甚至几小时，日志时间戳全乱套，排查问题时间线都对不上。装个NTP同步以为解决了，timedatectl status一查，NTP enabled: yes看着挺正常，可下面一行NTP synchronized: no——开关打开了，但压根没真同步成功。

开关打开不等于同步成功

timedatectl set-ntp true这条命令做的事，只是告诉系统"去试着同步"，不代表真的连上了时间服务器、拿到了准确时间。enabled: yes和synchronized: yes是两码事，前者是开关状态，后者才是真正的结果。同步没成功，常见原因是网络到时间服务器不通、配置的服务器地址本身有问题，或者防火墙把NTP用的端口挡住了。

VPS的时间问题，跟物理机不是一回事

物理服务器的时钟依赖主板上的硬件晶振，误差是那种缓慢的、可预期的"漂移"，攒够了偏差量再靠NTP慢慢纠正。但VPS的情况完全不同——虚拟机压根没有独立可靠的硬件时钟，它对"时间流逝"的感知，本质上是靠宿主机分配的CPU调度周期堆出来的。如果物理宿主机负载很重、这台VPS抢不到及时的CPU时间片，虚拟机的时钟不是慢慢漂移，而是会直接跳跃——一下子跳过去好几秒甚至更多，这跟之前写的VPS的CPU使用率明明很低为什么系统还是卡讲的其实是同一个根源：宿主机调度延迟。CPU被偷走的时候，你的程序在干等；时钟被偷走的时候，你的系统时间直接失真，两者都是虚拟化调度延迟这一件事在不同层面的体现。

chrony比传统ntpd更适合这种场景

正因为VPS遇到的是"跳跃"而不是单纯的"漂移"，处理方式也得跟着变。ntpd更擅长应付缓慢渐进的偏差，遇到大幅度跳变调整起来比较迟钝；chrony（RHEL 8以上已默认弃用ntpdate、只用chronyd）对突发跳变的适应能力明显更强，是目前更推荐在虚拟化环境下用的方案：

1
2
3

yum install chrony -y
systemctl enable chronyd
systemctl start chronyd

装好后手动确认同步状态：

1
2

chronyc tracking
chronyc sources -v

光同步系统时间还不够，硬件时钟也得对齐

NTP同步成功只解决了系统时间，服务器重启的时候，系统会去读一次硬件时钟（RTC）作为初始值，如果硬件时钟本身跟系统时间对不上，重启之后时间又会跳回错的那个值。同步一次，顺手也把硬件时钟校准了：

1

hwclock --systohc

另外确认一下硬件时钟存的是不是UTC（推荐用UTC，避免时区换算带来额外的混乱）：

1

timedatectl set-local-rtc 0

时间偏差特别大的时候，chrony默认调整策略可能太慢

chrony默认倾向于"温和纠正"，如果发现偏差特别大，慢慢调整可能要花很长时间才能追上。配置文件里加一条makestep，允许在偏差超过阈值的情况下直接跳到正确时间，而不是慢慢挪：

1

makestep 1.0 3

这条的意思是，如果时间偏差超过1秒，且是在chrony启动后的前3次更新之内，允许直接步进调整，不用等着慢慢靠近。

顺带一提

这种"网上抄来的一键优化脚本里塞了一堆参数，各管各的、互相之间关系没讲清楚"的情况，跟之前写的为什么开了BBR网速却感觉一点没提升是类似的坑——时间同步、网络加速这些配置经常被打包在同一份VPS初始化脚本里一股脑塞给你，跑之前多花两分钟弄清楚每一项具体在解决什么问题，比照单全收更靠谱。

ip -6 addr今天看的地址，隔几天再查，后半截莫名其妙变了，第一反应容易往坏处想——是不是配置被人动过手脚，或者哪个服务偷偷改了网络设置。其实大概率什么都没被入侵，这是IPv6一个专门设计出来的隐私保护特性在正常工作，只是这个特性放在服务器身上，通常并不是你想要的。

最早的IPv6地址，其实是个"永久身份证"

IPv6地址后64位（接口标识符）最早的生成方式叫EUI-64，直接把网卡的MAC地址原样嵌进去，好处是简单、不用协调就能保证唯一，副作用却很致命——这段后缀跟MAC地址死死绑定，不管设备换到哪个网络，暴露出来的这一截永远一样，等于给每台设备贴了张终身不变、全世界可见的身份证。安全研究者早就指出这是个隐私灾难，任何一方留意这个特征值，就能跨网络持续追踪同一台设备。

Privacy Extensions就是为了解决这个问题而生的

为了堵上这个漏洞，后来的标准（RFC 4941，现已被RFC 8981取代）给SLAAC加了Privacy Extensions机制——设备不再老实用MAC地址生成固定后缀，而是随机生成一段临时接口标识符，默认"首选"有效期约1天，完全失效前还有2天宽限期，快到期前系统自动生成新的随机地址顶替上去。地址隔一天左右自动换一次，是设计好该有的正常行为，不是故障也不是被篡改。

服务器和普通设备的需求正好相反

关键点在于：Privacy Extensions启用后，设备身上会同时存在两个地址——一个稳定地址负责让外界持续找到你；一个不断轮换的临时地址，专门用在设备主动发起的连接上，防止被追踪。这套设计是为终端设备（笔记本、手机）量身定制的。

但VPS的定位正好反过来——服务器存在的意义就是要被稳定地找到，域名解析、白名单、日志分析全指望这个地址长期不变。如果系统默认给VPS也开着这个特性，服务器主动向外发起的连接会不断换"马甲"，排查问题时日志里同一台机器顶着好几个不同IPv6地址，只会徒增困惑，没有实际隐私收益。

怎么确认现在是不是开着，以及怎么关

先查一下当前的设置：

1

sysctl net.ipv6.conf.all.use_tempaddr

返回值是2表示已经开启，且优先用临时地址发起新连接；0是完全关闭；1是生成但不优先使用。如果这台VPS上确实显示的是2，关掉它，让服务器的出站连接固定用稳定地址：

1
2
3
4

sysctl -w net.ipv6.conf.all.use_tempaddr=0
sysctl -w net.ipv6.conf.default.use_tempaddr=0
echo "net.ipv6.conf.all.use_tempaddr=0" >> /etc/sysctl.conf
echo "net.ipv6.conf.default.use_tempaddr=0" >> /etc/sysctl.conf

需要澄清一点：这个设置管的是服务器自己主动发起连接时用哪个地址，跟"别人怎么访问你这台服务器"是两码事——外部访问用的是你DNS里AAAA记录指向的那个稳定地址，关掉Privacy Extensions不会影响别人正常连进来，只会让你自己这台机器对外发起的连接不再莫名其妙换地址。

顺带一提

如果是在排查VPS被暴力破解怎么查有没有被入侵这类安全问题的过程中，看到日志里同一台自己的机器顶着不同IPv6地址出现，先别急着往"被入侵"这个方向想，回头查一下是不是这个特性在起作用。想确认自己这台VPS当前对外呈现的地址类型和质量，也可以配合推荐几个IP工具那篇提到的工具查一下，确认关闭Privacy Extensions之后地址确实稳定下来了。

ping -6一测，延迟正常、一个包都不丢，看着IPv6配置得妥妥的；结果打开一个网站，页面加载到一半就卡死不动，SSH倒是能连上，登录成功之后敲命令却半天没反应。小包一路畅通，大包寸步难行，这种诡异的"选择性失灵"，在IPv6下有个专门的名字——PMTU黑洞。

IPv6做了一个跟IPv4不一样的设计决定

IPv4时代，如果一个数据包大小超过了某段链路能承受的上限（MTU），中间的路由器可以直接把这个包拆开（分片）之后继续转发，麻烦是麻烦，但好歹能自己想办法解决。IPv6在设计上彻底废掉了路由器这个能力——中间路由器不允许分片，遇到超过链路MTU的包，唯一能做的就是把包直接丢弃，然后回发一个ICMPv6"Packet Too Big"消息告诉发送方"你这个包太大了，改用这个尺寸重新发"。这是个刻意的取舍：简化了路由器的工作、提升了转发效率，但代价是把"发现最优包大小"这件事完全甩给了两端，整个流程必须依赖这条"回复消息"能顺畅地传回发送方，这套机制叫路径MTU发现（PMTUD）。

黑洞出在哪一步

麻烦就出在这条"回复消息"上——路径上只要有任何一个防火墙或者中间设备，出于"安全考虑"或者单纯配置疏忽，把ICMPv6这类消息不分青红皂白地拦截或者丢弃掉，发送方就永远收不到"包太大了"这个提醒，只会一直傻乎乎地按原来的大尺寸继续发送，这些包在半路被反复丢弃，TCP只能靠自己超时之后重传来兜底，慢得让人抓狂，严重的时候干脆卡死不动。

这也是为什么ping能通但网站打不开——ping用的探测包体积很小，怎么都不会撞上MTU这道坎，畅通无阻；而网页的实际内容数据、SSH认证成功之后的正常会话数据，动辄接近甚至超过完整MTU尺寸，一旦触发"包太大需要缩小"这个反馈机制，恰好又被沿途某个防火墙拦下了这条反馈消息，就成了黑洞——连接建立起来了（因为握手包够小），真正传数据的时候却卡死。有人真的用tcpdump抓包验证过这个现象，能清楚看到对端发回的ICMP6, packet too big, mtu 1285这条消息，说明路径中某一段链路的MTU只有1285字节，远小于常见的1500。

怎么确认自己遇到的是这个问题

对照几个典型症状，如果你现在的情况能对上大半，基本可以锁定就是PMTU黑洞：TCP连接能正常建立（因为握手包小）；网页加载到一半卡住不动；SSH能连上，认证成功后却卡死；文件下载开始几KB之后就停滞不前。

怎么解决

核心思路是确保ICMPv6的"Packet Too Big"这条消息（Type 2）在整条路径上畅通无阻，检查自己VPS上的防火墙规则，明确放行这类消息：

1
2

ip6tables -I INPUT 1 -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT
ip6tables -I OUTPUT 1 -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT

如果自己这边的防火墙确认没问题，问题还是没解决，说明黑洞出在你控制不了的上游链路某处，这种情况下自己这台VPS改配置帮不上忙，只能等对方网络修复，或者换一条不经过这段问题链路的路由。

顺带一提

同样是"IPv6看着配置好了，实际却在拖后腿"这类问题，之前写的为什么VPS各种连接、下载都很慢，罪魁祸首可能是IPv6讲的是另一种情况——那篇是连接建立阶段就被拖慢，这篇是连接建立之后传数据被卡死，两种症状容易混在一起，遇到问题先分清楚是"连不上"还是"连上了传不动"，排查方向完全不同。如果确认问题出在SSH这个具体场景，另外还有一篇专门讲VPS SSH连接很慢是什么原因，讲的是跟MTU完全无关的另外两个常见原因，也可以对照排除。

带宽测过、路由也查过，数据看着都正常，但VPS上敲个wget就是要愣个一两秒才开始下载，SSH连接偶尔也要卡一下，说不上哪里坏了，就是整体感觉"慢半拍"。这种笼统的慢，很多时候压根不是带宽或者CPU的问题，是系统每次新建连接的时候，先去尝试了一个根本走不通的IPv6，白白等了一截超时时间。

系统本来是有防呆设计的

现代操作系统和大部分应用，处理"域名同时解析出IPv4和IPv6两个地址"这种情况时，用的是一套叫Happy Eyeballs（RFC 8305定义）的机制——同时发起IPv4和IPv6两路连接尝试，优先偏向IPv6，但哪个先连通就用哪个，不会傻等一条线路。这个设计的初衷就是为了应对"IPv6配置得七零八落"这种普遍存在的现实情况，理论上就算你的IPv6是坏的，也只会因为要等一下IPv6失败的信号，多花大概两三百毫秒，不至于让人有明显感知。

但这套防呆机制，不是所有软件都老实实现了

问题就出在这——Happy Eyeballs是个"建议标准"，不是所有客户端软件都规规矩矩照着实现。真实翻过车的例子：Node.js底层网络库undici，压根没实现这套机制，一旦域名同时解析出IPv4和IPv6，它会先死磕IPv6，等到完整的连接超时时间耗尽才肯回落到IPv4，这个等待时间可以是好几秒，远不是设计初衷里那两三百毫秒的"温和延迟"。像curl这类正确实现了Happy Eyeballs的工具，同样的网络环境下访问就完全正常，反而更容易让人误以为是"某个具体命令有问题"，而不是往IPv6这个方向去想。

什么样的IPv6配置最容易踩这个坑

最麻烦的不是"完全没有IPv6"，也不是"IPv6配置得很干净"，而是看着有、实际走不通的这种半吊子状态：

• 有IPv6地址，但没有默认路由，包发出去了却压根不知道该往哪转发
• 防火墙默默丢弃IPv6流量而不是明确拒绝——静默丢包比直接拒绝更麻烦，因为拒绝能让客户端立刻知道这条路走不通，静默丢包只能靠等超时才能确认失败
• 服务器本身AAAA记录已经解析出去了，但IPv6网络配置其实还没真正弄好

排查思路，先确认这台机器的IPv6是不是真的能用：

1
2
3

ip -6 addr show scope global
ip -6 route show default
ping -6 baidu.com

如果地址显示不完整（只有link-local这种本地链路地址）、或者压根没有默认路由、或者ping不通，基本可以确定就是这个"半吊子IPv6"在拖后腿。

怎么解决

思路只有两条，选一条走到底，最忌讳的就是停在中间这个半吊子状态：要么把IPv6配置彻底修好（补上默认路由、确认防火墙没有静默丢包），要么干脆利落地关掉，让系统压根不去尝试这条走不通的路，连Happy Eyeballs那两三百毫秒的等待都省了。关闭方式具体怎么操作、有哪些容易被忽略的细节（比如lo接口漏关、NetworkManager在背后跟sysctl打架），可以看之前写的为什么改了disable_ipv6，IPv6却还是没有被真正关掉那篇，把这一步做干净了，"莫名其妙变慢"这个问题往往也就跟着消失了。

如果这台VPS本身就是IPv6 only、或者IPv6是核心需求不能一关了之，那思路就完全反过来了，得把IPv6彻底修通而不是关掉，具体排查方法可以看IPv6 VPS服务无法访问的常见原因与排查方法那篇。

某些场景下想彻底关掉IPv6（比如某个服务对IPv6支持有问题，干脆关掉省心），常见做法是改/etc/sysctl.conf加一行net.ipv6.conf.all.disable_ipv6=1，跑一下sysctl -p，结果ip -6 addr一查，IPv6地址还在，跟没改过一样。要么就是反过来——真关掉了，过阵子发现SSH的某个功能用不了了，或者邮件服务死活启动不起来，两头都能踩坑。

“all"不等于"所有”

第一个坑出在这个参数的名字容易让人误会。net.ipv6.conf.all.disable_ipv6=1看着像是"关闭所有接口的IPv6"，实际上它只是给新建立的接口设置默认值，加上作用到已经存在的常规网卡上；但回环接口（lo）不受它管，得单独再加一行：

1
2
3

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

社区里翻车的人不少都是只写了第一行，觉得all听着应该管得够全了，结果lo接口上的IPv6死活关不掉。

NetworkManager会在背后跟你唱反调

如果系统用的是NetworkManager管理网络（常见于RHEL/CentOS这类发行版），就算sysctl这边配置全部写对了，NetworkManager有自己的一套逻辑，可能会在网卡重新连接的时候，把IPv6又悄悄打开，跟sysctl的设置对着干。这种情况下光改sysctl没用，还得额外用nmcli单独告诉NetworkManager本身也别管IPv6：

1

nmcli connection modify "连接名" ipv6.method "disabled"

两边都设置了，才算真正锁死。

真想彻底关掉，得从内核启动参数下手

如果sysctl这条路来回折腾还是不干净，更彻底的办法是在GRUB里加内核启动参数ipv6.disable=1，这样重启之后IPv6模块压根不会被内核加载。这里有个有意思的连锁反应——如果之前sysctl.conf里还留着net.ipv6.conf.all.disable_ipv6=1这一行没清理，下次sysctl -p反而会报错，提示cannot stat /proc/sys/net/ipv6/conf/all/disable_ipv6: No such file or directory，因为内核层面IPv6压根不存在了，这个参数自然也没了，两种关闭方式叠加，变成新的报错，得把旧配置一并清掉。

关掉之后，别的服务可能跟着遭殃

IPv6被真正关掉之后，一些服务默认监听::1这种IPv6回环地址，会直接启动失败——比较典型的是Postfix邮件服务，配置文件里inet_interfaces默认写法可能依赖IPv6回环，得手动改成指向IPv4的127.0.0.1才能正常跑起来；SSH的X11转发功能同样可能受影响，需要在sshd_config里加上AddressFamily inet明确指定只用IPv4。这些副作用平时不会显现，只有真把IPv6关掉那一刻才会冒出来，排查起来容易让人摸不着头脑，表面上看跟"关IPv6"这个操作完全不沾边。

顺带一提

这种"配置文件明明改了，实际却没在预期的地方生效"的情况，跟之前写的ulimit设置了却不生效是同一类问题的不同变种——不是配置写错了，是改的那个地方，压根管不到你以为它管的那个东西。如果反过来是VPS本身IPv6 only、根本没有IPv4可以选择性关闭，遇到的会是完全不同方向的连接问题，可以看IPv6 VPS服务无法访问的常见原因与排查方法那篇，一个是"关不掉"，一个是"只有它、还连不上"，别搞混排查方向。

服务并发一上来，日志里开始刷屏Too many open files，查了一圈发现是文件描述符（也就是nofile）限制不够用，照着教程改了/etc/security/limits.conf，重新登录敲一下ulimit -a，数字确实变大了，满心以为解决了，结果服务重启之后照样报同样的错，跟没改过一模一样。

你改对了地方，但改错了对象

问题的根源在于——/etc/security/limits.conf这个文件，从来就不是给系统服务用的。它的官方文档说得很直白：“This file sets the resource limits for the users logged in via PAM…It does not affect resource limits of the system services.”（这个文件设置的是通过PAM登录的用户的资源限制，不影响系统服务的资源限制。）

你改完这个文件，重新SSH登录一次，确实能看到ulimit -a里的数字变了——但那只是你这次登录会话通过PAM认证之后继承到的限制，跟你用systemctl start、docker run这类方式启动的后台服务完全是两码事。这些服务压根不是通过你的登录会话拉起来的，自然也就轮不到limits.conf来管它们。有人真的做过对比实验：改完limits.conf，自己的shell里ulimit -a显示正常，但MySQL服务本身查询它实际生效的open_files_limit，数值纹丝不动还是原来的1024。

systemd是故意这么设计的，不是漏掉了

更准确地说，这不是"没生效"，是systemd在设计上就故意无视这个全局配置文件，官方文档原话是"Systemd does not support global limits, the file is intentionally ignored"（systemd不支持全局限制，这个文件被有意忽略）。systemd有自己独立的一套限制机制，得单独针对每个服务去配置。

正确的改法：给具体服务单独配置

以Nginx为例，给它专门建一个systemd覆盖配置，不用去动主配置文件：

1
2
3
4
5
6
7

mkdir -p /etc/systemd/system/nginx.service.d/
cat > /etc/systemd/system/nginx.service.d/override.conf << EOF
[Service]
LimitNOFILE=100000
EOF
systemctl daemon-reload
systemctl restart nginx

把nginx换成你实际要调整的服务名（比如docker、mysqld，或者你在跑的某个代理面板对应的服务名），思路都一样。

还有两层隐藏的天花板

就算这一步配对了，也可能碰到另外两层限制：一是内核本身有个硬顶/proc/sys/fs/nr_open，你设置的数值不能超过这个内核级上限；二是CentOS 7上曾经存在过一个已知的systemd bug（低于240版本），LimitNOFILE这个参数即使写了也不生效，需要额外手动干预才能真正吃到配置。遇到配置写对了但还是不生效的情况，这两个方向值得往下查。

顺带一提

如果这台VPS上跑着Uptime Kuma这类需要同时维持大量监控连接的探针服务，文件描述符不够用的问题会比一般场景更容易碰到，配置的时候可以适当留足余量。之前写VPS磁盘空间满了怎么排查那篇里提到用lsof排查文件占用的方法，跟这篇讲的文件描述符本质上是同一套底层机制，遇到跟"打开的文件太多"相关的报错，这两篇可以放一起对照着看。

一个进程行为异常，一般人的应对顺序是kill、不行就kill -9——后者理论上是终极武器，连进程自己都没机会拒绝，操作系统直接把它强制终止。结果偏偏有些时候，kill -9敲下去，ps一查，那个进程还稳稳地待在那儿，跟没发生过一样，第一次遇到这种情况会怀疑自己是不是敲错了命令。

kill其实只是"传话"，不是"处决"

kill命令本质上是给目标进程发一个信号，再交给操作系统内核去处理。内核收到信号之后，正常情况下会中断进程当前在做的事，转去处理这个信号——但这里有个前提：进程得处于一个"能被打断"的状态。

Linux进程有好几种状态，其中两种睡眠状态是关键：一种是可中断睡眠（S状态），进程在等某个事件的时候，收到信号会立刻被唤醒去响应，这是绝大多数进程平时的正常状态；另一种是不可中断睡眠（D状态，也就是top/ps里显示的那个字母），这种状态的进程完全不接收任何外来信号，不管是普通的kill、kill -9还是kill -15，通通不管用。之前写Load Average很高是不是要出问题了那篇提到的，被算进负载却根本不占CPU的那批进程，正是这个D状态。

为什么内核要设计成"不可中断"

D状态出现的场景，通常是进程正在等待磁盘、网络这类硬件IO返回结果，而这个等待处在内核态一个很关键的环节里——为了保证数据一致性（比如磁盘正在写入的数据不能被半路打断），内核干脆把这类等待设计成任何信号都传不进去，这不是bug，是故意的保护机制，只是这个保护机制的副作用就是"连SIGKILL都杀不掉"。

一个真实会发生的场景

比较典型的情况是挂载了NFS这类网络文件系统，如果NFS服务端突然断开或者不响应了，客户端这边正在往这个挂载点写数据（比如执行mv、cp这类命令），进程就会卡在等待IO返回的环节，直接进入D状态。这时候你kill -9它，命令执行不报错，但进程原地不动，ps -ef看它状态栏赫然写着D，怎么杀都杀不掉，跟撞了铁板一样。

真正能解决问题的办法

D状态进程能恢复正常，唯一靠谱的路子是让它等的那个IO资源重新可用——上面NFS的例子里，就是把NFS服务端连接恢复，进程发现自己等的数据终于来了，会自己顺利跑完然后正常退出，不需要你手动杀它。如果这个IO资源短期内没法恢复（服务端确实挂了、修不好），比较现实的办法就是直接重启这台机器，虽然简单粗暴，但相当于把内核里所有卡住的状态一次性清空，比研究怎么绕过信号机制强行终止要省事得多。

理论上也存在更极客的做法——写一个内核模块，直接在内核层面遍历进程列表，把D状态进程的状态位强行改掉再杀，网上确实能找到这类实现。但这属于直接动内核数据结构，风险不小，除非你完全清楚自己在干什么、并且这个进程你确认可以安全放弃，不然不建议普通场景下这么折腾。

跟Load Average那篇是同一个根

看到这里应该能明白，之前那篇讲的"Load Average虚高但CPU不忙"、这篇讲的"kill -9杀不掉进程"，说的其实是同一批D状态进程的两种不同表现——它们不占CPU却被算进负载，它们不听任何指挥却稳稳占着系统资源。下次再遇到进程杀不掉，先别怀疑自己敲错命令，用ps -ef看看它是不是显示着一个D，如果是，问题的根源在等的那个IO资源上，不在你这条kill命令上。

服务器跑着跑着突然开始报"无可用端口"、连接建立不上，netstat -an | grep TIME_WAIT | wc -l一查，几万个连接卡在TIME_WAIT状态动弹不得。这种情况在跑代理面板、反向代理这类需要频繁建立短连接的服务上特别常见，很多人第一反应是去搜"TIME_WAIT优化"，抄一段网上流传很广的内核参数配置，结果有的抄对了，有的抄了个更大的坑。

TIME_WAIT不是浪费，是保护机制

TCP连接主动关闭的那一方（通常是发起连接的客户端，也可能是主动断开的服务端，比如反向代理去连后端），断开之后不会立刻释放这个端口，而是停留在TIME_WAIT状态一段时间（标准时长是2倍的MSL，Linux下这个总时长通常在1分钟左右）。这段时间不是白等的，它在防两件事：一是防止这个连接里还在网络上漂着的延迟旧数据包，被误认成属于后面复用了同一个四元组（本地IP、本地端口、远端IP、远端端口）的新连接；二是保证四次挥手最后那个ACK包如果丢了，对方重传FIN的时候，这边还能正常响应，不会导致连接没法正常关闭。

这套机制存在了几十年，是TCP协议本身故意这么设计的，不是Linux的失误。

什么情况下会真的端口不够用

TIME_WAIT状态的连接占用的端口不能被同样四元组的新连接复用，如果短时间内建立、断开连接的频率特别高（典型场景就是代理服务处理大量客户端的短连接请求），TIME_WAIT堆积的速度超过它自然过期释放的速度，可用端口池就会被迅速耗尽——本地端口范围默认大概是2.8万个左右，tcp_max_tw_buckets这个参数（默认1.8万左右）同时也在限制系统能同时保留的TIME_WAIT连接总数，两者取较小值，就是这台机器实际能扛住的上限。

网上流传的"修复方法"，一半好用一半是坑

搜TIME_WAIT优化，十有八九会同时搜到两个参数打包出现：tcp_tw_reuse和tcp_tw_recycle，很多老教程让你把两个一起打开，这个建议只对了一半。

tcp_tw_reuse相对安全，打开之后能让本机在满足条件（主要靠TCP时间戳判断新旧连接不会冲突）的情况下，快速复用还处于TIME_WAIT状态的端口去发起新连接，主要在你的服务器作为客户端主动连出去的场景（比如反向代理连后端）时有效：

1

sysctl -w net.ipv4.tcp_tw_reuse=1

tcp_tw_recycle就是那个坑了——这个参数在Linux 4.12版本已经被彻底移除，但很多老教程写的时候它还在，抄这些老教程在新内核上会直接报错设置不了；更要命的是，就算是在还保留这个参数的老系统上，打开它对处于NAT网络后面的客户端极度不友好——同一个NAT出口下的不同用户，因为时间戳判断逻辑的缺陷，会出现连接被错误拒绝、访问不了服务的情况，公网服务打开这个参数，等于把一部分NAT后面的正常用户直接拒之门外。这不是危言耸听，这个坑连大厂都踩过，后来的内核版本干脆把这个参数直接删掉了断绝后患。

线上服务不建议打开tcp_tw_recycle，如果是老教程抄来的配置文件里还留着这一行，建议删掉。

更稳妥的应对方式

除了tcp_tw_reuse，把tcp_max_tw_buckets适当调大也是常见做法，给系统更大的TIME_WAIT缓冲空间：

1

sysctl -w net.ipv4.tcp_max_tw_buckets=55000

如果这台VPS上跑的是多协议代理一键脚本这类需要处理大量并发连接的服务，这几个参数值得留意一下，别等到端口耗尽报错了才想起来查。跟之前为什么开了BBR网速却感觉一点没提升一样，这类内核网络参数经常被打包在同一份"VPS优化脚本"里一股脑塞给你，弄清楚每个参数具体在做什么、哪些能抄哪些不能抄，比照单全收更重要。

跑一下uptime，Load Average显示8点多，第一反应是CPU要炸了，赶紧top一看，CPU使用率却只有百分之十几，两个数字对不上，人都懵了——到底是该慌还是不该慌？

这个数字从一开始就不是"CPU使用率"

Load Average统计的是过去一段时间内，处于可运行状态（Running）和不可中断等待状态（Uninterruptible Sleep，也就是top/ps里显示的D状态）的进程平均数量。前半句"可运行状态"好理解，是真的在抢CPU的进程；后半句这个D状态才是问题所在——它指的是进程正在等磁盘、网络这类IO操作返回结果，而且这个等待不能被信号打断（内核为了保证数据一致性，故意设计成这样，比如磁盘数据还没读完，不能被其他操作插队打断）。

问题就出在这——D状态的进程根本不需要CPU，纯粹是在等IO，但Linux硬是把它算进了Load Average这个本该反映"CPU有多忙"的指标里。所以看到Load Average很高，你其实完全不知道这是CPU真的不够用了，还是磁盘/网络卡住了一堆进程在傻等，这个数字从设计上就没法单独说明问题。

为什么会这样设计，还得从1993年说起

这不是bug，是个有历史渊源的设计决定。查资料的时候翻到一个挺有意思的细节：早在1993年，Linux的设计者就讨论过这个问题，当时的逻辑是——D状态的等待通常很短暂，很快就会恢复，干脆算作"约等于在排队等CPU"。有人还做过一个很直观的验证：把系统的磁盘从快的换成慢的，Load Average会跟着涨——单纯换个慢一点的硬盘，跟CPU有没有多忙半点关系都没有，涨的完全是D状态进程数量。这个设计决定从三十多年前定下来，一直沿用到今天，也就一直带着这个容易让人误判的副作用活到了现在。

真正该看的是CPU使用率和D状态谁在唱主角

遇到Load Average偏高，先别急着断定是CPU不够用，跑一下：

1

top

看%us（用户进程占用）和%sy（系统进程占用）这两项，如果确实很高，那是真的CPU吃紧了；如果这两项都不高，反倒是%wa（等待IO）这一项很显眼，说明大概率是磁盘IO在拖后腿，不是CPU的问题。

想更直接地揪出到底是哪些进程在D状态里干等着：

1

ps aux | grep " D "

看到的进程通常是在等磁盘读写、等网络存储（比如挂载了NFS）响应，顺着这些进程往下查，能更快定位到真正的瓶颈在哪。

一个大致的判断参考

经验上，Load Average低于CPU核心数，一般不用太担心；超过核心数的70%左右，响应速度可能会开始感觉变慢；持续超过核心数好几倍，才是真正需要重视的信号。但记住这个数字终究是"运行中+等待IO"的混合体，光看这一个数字下结论，跟只看体温不看具体哪里发炎一样，容易找错方向。

之前写过的VPS的CPU使用率明明很低为什么系统还是卡和这篇讲的是两码事——那篇是CPU被虚拟化层抢走了，这篇是IO把进程卡住了，症状看着都是"感觉很卡"，但排查方向完全不一样，混着看容易把自己绕晕。

网上一搜BBR教程，标题动不动就是"网速提升3倍"“涡轮增压”，跟着敲完三行命令，兴冲冲测个速，发现数字跟开之前差不多，甚至一模一样。很多人到这一步就得出结论："BBR就是个噱头，没用。"这个结论下得有点冤——问题往往不在BBR本身，而在对它的期待从一开始就搞错了方向。

BBR到底在优化什么

BBR是一种拥塞控制算法，它管的是数据包在网络出现拥堵时该怎么应对，不是给你的服务器凭空变出更多带宽。传统的Cubic算法看到丢包就本能地大幅减速，哪怕丢包只是网络抖动一下，跟真正的拥堵没关系，它也会误判，结果该跑的带宽没跑满。BBR不这么干，它会持续估算这条链路真实的带宽上限和往返时间，尽量把发送速率精确地贴着这个上限走，不会因为一点风吹草动就自废武功。

节点论坛上有个说法挺形象："垃圾线路，你用BBR，50分，调优TCP，55分；好的线路，你用BBR，90分，调优TCP，95分。"意思很直接——BBR是给线路本身的质量做加法，不是从0变出100。这条链路物理上能跑多快是有天花板的，BBR顶多帮你更接近这个天花板，天花板本身有多高，它说了不算。

什么情况下BBR基本感觉不出差别

如果你测速的目标是同城、甚至同一个数据中心内部的节点，延迟本来就低到几毫秒，链路干净得几乎不丢包，这种场景下Cubic和BBR的表现差距很小——因为压根没什么"拥堵"需要被更聪明地应对，两种算法交出的答卷自然相差无几。BBR真正大放异彩的场景，是跨洋、跨运营商、延迟动辄上百毫秒、偶尔还丢包的链路，这种情况下传统算法的保守应对方式会白白浪费掉大量本该能用上的带宽，BBR的优势才真正体现出来。拿同城测速的结果去否定BBR，本身就是拿错了考卷。

除了原理，还有几个技术上的坑

除了期望值搞错，也有不少是BBR压根没真正生效导致的：

sysctl设置完tcp_congestion_control=bbr，不代表配置全对了，配套的队列调度算法qdisc同样得设成fq，不然内核实际用的还是默认的pfifo_fast，BBR跑起来的效果会打折扣：

1

sysctl net.core.default_qdisc

确认输出是fq（或者较新内核用fq_codel），不是别的。

老内核压根不支持BBR，sysctl命令执行时不报错，看着像是设置成功了，重启之后拿命令一验证，发现又悄悄变回了cubic：

1

sysctl net.ipv4.tcp_congestion_control

如果验证结果不是bbr，说明内核版本不够，得先升级内核才行，不是配置写错了。

还有个容易被忽略的情况——如果这台VPS上同时跑着好几条代理连接，物理带宽早就被这几条连接瓜分完了，单条连接测出来的速度自然上不去，这不是BBR的锅，是带宽本身已经被占满了。

该怎么判断BBR到底有没有用

最靠谱的办法不是跟别人的"提升3倍"截图比，是用自己这台机器的实际线路，开BBR前后各测一次，对比同样的目标、同样的时间段。如果这台VPS本身线路质量就一般，之前提过的CPU使用率明明很低系统却卡那篇里讲的超售问题，同样会拖累网络表现，BBR再怎么调也调不出一条干净的物理线路；测速工具的选择也有讲究，具体可以看VPS网络测速用什么工具最好，用对工具测对场景，才能看出BBR到底帮没帮上忙。