授权与合规声明
本文全部操作对象均为自建隔离靶场（本机容器或隔离虚拟机），涉及安全测试的环节必须以取得合法授权为前提。未经授权的渗透测试违反《中华人民共和国网络安全法》与《刑法》相关条款，须承担相应法律责任。本文只讲环境配置、版本对照与靶场隔离，不含任何攻击步骤、利用载荷与绕过手法，请勿将文中环境指向任何非自有系统。
一、“停不掉”其实是三件事
1.1 先把这句话拆成三类
在靶场里改完配置、重启服务，遇到起不来的情况，绝大多数人第一句话是“端口没放出来”。这句话听起来像一件事，实际上至少是三件事的合称，而且三件事的观察位置完全不同。
第一件是进程还在。服务的进程没有真正退出，监听套接字还握在它手里，新进程去绑同一个地址和端口，当然失败。这一层的证据在进程表里，不在连接表里。
第二件是进程退了，记录还在。连接关闭以后，协议栈不会立刻把这条连接的四元组丢掉，先关闭的那一端要留一段时间，这就是 TIME-WAIT。这时候你看进程表是干净的，看连接表还有东西，于是很容易误判成“进程没死”。
第三件是规则层面不允许。绑定失败不一定因为有人占着，也可能因为地址校验这一关没过——套接字选项有没有在绑定之前设上，会直接改变哪些绑定是允许的。
三件事混在一起排查，最常见的结局是得出“重启一下就好了”或者“等一会儿就好了”。这类经验在单机上碰巧有效，换一台机器、换一个场景就失效，因为它没有指向任何一个具体的层。
| 现象 | 真正的原因在哪一层 | 证据看哪里 | 本文是否展开 |
|---|---|---|---|
| 服务停了，进程还在跑 | 进程层 | 进程表、监听套接字 | 只在第七章给一个观察动作 |
| 进程没了，连接表里还有残留 | 协议栈的连接层 | 连接表（状态与四元组） | 第二至五章 |
| 进程没了、连接也干净，还是绑不上 | 绑定规则层 | 代码里 bind 之前设的选项 | 第六章 |
| 以上都不是 | 绑定之外的其他原因 | 不在本文范围 | 否 |
第四行是有意留白的。同一类“起不来”还有别的成因，和连接关闭没有关系，本文不碰。
1.2 判断“是谁留下的”，先看谁先关
规范把这件事写得很直白。RFC 9293（截至 2026-10-20 的现行版本）第 3.5 节的原文是：
When a connection is closed actively, it MUST linger in the TIME-WAIT state for a time 2xMSL (Maximum Segment Lifetime) (MUST-13).
这句话的主语是关键：主动关闭的那一方。所以看到一条 TIME-WAIT 记录，第一个要回答的问题不是“怎么把它清掉”，而是“这条连接是谁先发的关闭”。
短链接触发的场景里，通常是请求方先关；服务端因为超时、因为业务逻辑主动断开、因为进程退出而发出的关闭，服务端就是主动关闭方。同一个服务端口上，这两种情况下被占住的东西并不是同一个，第五章会把这件事拆开。
1.3 本文的范围，以及一句必要的声明
需要先把范围说清楚：TCP 状态机全貌不在本文范围。那些状态各自什么时候进、什么时候出，是一整套东西，本文不铺开，需要那一层的读者直接读 RFC 9293 第 3.4.2 节。本文只引用 TIME-WAIT 一个状态的定义，因为“端口为什么还没放出来”这个问题，只和这一个状态有关。
只讲一个状态，不是偷懒。相反，把注意力收窄到一个状态上，才有可能把这一个状态讲透：它为什么存在、它存在多久、它占的是谁的资源、以及哪些做法是误解。
二、连接关闭是四次交互
2.1 为什么是四次而不是两次
TCP 是全双工的。同一条连接上有两个方向的数据流，各自独立地开始、独立地结束。这一点决定了关闭不能一次说完。
一端说“我没有数据要发了”，只表示它到自己这个方向结束了；对端可能还有没发完的数据。所以关闭要分成四步：一端发出结束请求，另一端确认；等另一端自己也没数据了，再发出它那一侧的结束请求，最后由最初那一端确认。
如果硬要压缩成两次，就得让“我不发了”和“你也不要发了”绑在一起，那等于单方面掐断对端还在传输的数据。所以四次的本质不是协议啰嗦，而是两个方向必须分别确认。
2.2 四次交互各自“清了什么”
| 次序 | 方向 | 携带的语义 | 清掉的是什么 |
|---|---|---|---|
| 第一次 | 主动关闭方 → 对端 | 本方向不再发送数据 | 主动关闭方这一侧的发送通道 |
| 第二次 | 对端 → 主动关闭方 | 收到上面的声明 | 一个悬而未决的确认 |
| 第三次 | 对端 → 主动关闭方 | 对端这一侧也结束 | 对端这一侧的发送通道 |
| 第四次 | 主动关闭方 → 对端 | 确认对端的结束 | 最后一个悬而未决的确认 |
四次走完，双方的发送通道都关了。注意一个容易被忽略的点：前两次和后两次之间是可以有间隔的。第二次确认发出去以后，对端可能还有数据要传，这段间隔在协议里是允许的，连接处于一种“半关”的中间态。这就是为什么抓包时会看到关闭过程拖得很长——不是网络慢，是有一端确实还有东西没发完。
2.3 第四次发出之后，为什么不能立刻消失
这是整篇文章的转折点，值得停一下。
第四次的那个确认发出去，主动关闭方在逻辑上已经没事可做了。但它不能立刻把这条连接的所有痕迹抹掉，原因在于：这个确认本身可能丢。
如果它丢了，对端收不到，就会认为第三次的结束请求没被确认，于是重发。重发的这个报文到达时，主动关闭方如果已经把这条连接忘干净了，就会用一个全新的上下文去接一个旧连接的报文——序列号对不上，轻则回一个复位，重则把新旧两条连接的数据搅在一起。
RFC 9293 第 3.4.3 节把底层原因写得很清楚：
every segment emitted occupies one or more sequence numbers in the sequence space, and the numbers occupied by a segment are “busy” or “in use” until MSL seconds have passed.
也就是说，一个报文占掉的序列号，在 MSL 秒之内都算“仍在占用”。这段时间里，同一对地址和端口之间如果起一条新连接，它的序列号空间就有可能和旧连接残留的报文重叠。TIME-WAIT 就是用来把这段重叠窗口挡住的。
所以 TIME-WAIT 不是“关不干净”，而是关得太干净反而会出问题。
三、TIME-WAIT 为什么必须存在
3.1 定义里其实写了两件事
RFC 9293 第 3.4.2 节给这个状态的定义是：
TIME-WAIT - represents waiting for enough time to pass to be sure the remote TCP peer received the acknowledgment of its connection termination request and to avoid new connections being impacted by delayed segments from previous connections.
一句话里塞了两个职责，值得逐段拆：
第一个职责是“确保对端收到了它那次终止请求的确认”。对应 2.3 讲的确认丢失问题——等够时间，即使确认丢了、对端重发了，重发的报文也会在这段等待期内被正确处理。
第二个职责是“避免新连接被上一条连接的延迟报文影响”。对应序列号空间的重叠问题——等够时间，旧报文要么已经到达并被丢弃，要么已经在网络中消失。
两个职责对应两个不同的故障场景：
| 职责 | 对应的问题 | 不等待的后果 |
|---|---|---|
| 确保对端收到终止确认 | 第四次交互的确认丢失、对端重发 | 重发的报文打到一条已不存在的连接上 |
| 避免旧报文影响新连接 | 延迟报文在路径上滞留 | 旧报文被新连接误认为自己的数据 |
3.2 两个职责为什么不能用别的办法替代
有人会想：既然只是等，那能不能让新连接用一个完全不同的序列号起点，绕开重叠？规范其实考虑过这件事。RFC 9293 第 3.5 节那一段紧接着还有一句：TIME-WAIT 状态下可以接受对端发来的新 SYN 直接重建连接，但前提是两条：新连接用的初始序列号必须大于上一条连接用过的最大序列号；并且如果这个 SYN 被判定为旧连接的重复报文，就要退回 TIME-WAIT。
这两条前提说明了一件事：跳过等待是有条件的，条件本身就是在防重叠。它不是“允许抢占”，而是“在能证明不会重叠的前提下提前放行”。证明不了，就老实等。
这也是本文不写“怎么让 TIME-WAIT 消失”的原因。规范给了提前重建的路径，但走这条路要做序列号比较，那是协议实现内部的事，不是使用者能拍脑袋决定的。
3.3 它是“等”，不是“卡”
初学者看到连接表里一堆 TIME-WAIT，第一反应是“出问题了”。这个判断需要纠正。
TIME-WAIT 有三个特征，每一个都和“故障”相反：它是有界的，等待时长由规范给定，到点自动结束；它是自动的，不需要任何人工干预；它是局部的，只锁住那一个四元组，不影响别的连接。
对照一下真正需要处理的情况：进程残留不会自己消失，你不处理它就一直占着；绑定规则不满足不会随时间好转，你不改代码就一直绑不上。TIME-WAIT 和这两者最本质的区别，就是它会自己走完。
所以正确的态度不是“消灭它”，而是“知道它在那儿、知道它占的是什么、知道它什么时候走”。
四、2×MSL 这个数怎么来的
4.1 MSL 是一个假设值，不是一个测量值
MSL 是 Maximum Segment Lifetime 的缩写，指一个报文在网络中能存活的最长时间。
这里要特别强调“最长”两个字是规范给的上界假设，不是任何一台设备测出来的实际值。真实网络里一个报文活多久，取决于经过多少跳、每跳怎么排队、有没有环路，没法给出统一数字。所以规范不去测它，而是规定一个值，让所有实现按同一个假设去算等待时长。
理解这一点，后面很多困惑就自然消解了：你在这台机器上量出来的 TIME-WAIT 时长，和规范写的数字对不上，不代表谁错了，只代表实现选了自己的取值。
4.2 规范取 2 分钟，于是等待是 4 分钟
RFC 9293 第 3.4.2 节的原文是：
For this specification the MSL is taken to be 2 minutes. This is an engineering choice, and may be changed if experience indicates it is desirable to do so.
原文自己就承认了这是“工程选择”（engineering choice），而且明确说可以改。这句话很重要，它把“4 分钟”从一个铁律降格成了一个默认约定。
按这个取值算：主动关闭方停留在 TIME-WAIT 的时长 = 2 × MSL = 4 分钟。
这是规范取值，不是本机实测值。实际实现可能不同，不同系统的默认取值也可能不同。写文章时把这两者混为一谈，是这类内容最常见的失真来源。
| 量 | 取值 | 性质 | 能不能改 |
|---|---|---|---|
| MSL | 2 分钟 | 规范给定的工程选择 | 规范原文说可以，视经验而定 |
| 2×MSL | 4 分钟 | 由上一行直接算出 | 随上一行变化 |
| 某台机器上的实际等待时长 | 未在本文实测 | 实现细节 | 不在本文范围 |
4.3 为什么偏偏是两倍
一倍不够，两倍刚好，原因在方向上。
考虑最坏情况：主动关闭方发出的最后一个确认，在路径上走了接近 MSL 才丢；对端等不到确认，重发它的结束请求，这个重发又要走接近 MSL 才到达。两段加起来就是 2×MSL。等待期必须覆盖这个最坏情况，否则重发的报文会在等待期之后到达，正好撞上新连接。
再叠上 2.3 里那条“序列号在 MSL 秒内都算占用”，两个 MSL 的窗口刚好把旧连接占用过的序列号全部熬过去。所以两倍不是拍出来的，是两个方向各一次的最坏延迟相加。
五、占的是哪个端口
5.1 一条连接由四元组确定
一条 TCP 连接由四个要素唯一确定：源地址、源端口、目的地址、目的端口。
TIME-WAIT 锁住的就是这整个四元组，而不是单独一个端口号。这一条是理解“端口复用”的前提：同一时刻，同一个本地端口完全可以出现在多条连接里，只要对端地址或对端端口不同。所以“端口被占了”这个说法，严格讲应该是“这个四元组被占了”。
反过来说，一个监听端口能同时接受很多连接，靠的也正是四元组不同——每个进来的连接，对端地址端口都不一样。
5.2 谁主动关，决定被占住的是谁
| 主动关闭方 | 被 TIME-WAIT 锁住的四元组 | 表现出来像什么 |
|---|---|---|
| 请求方（客户端） | 客户端临时端口 + 服务端地址端口 | 客户端短时间内反复连同一服务，临时端口吃紧 |
| 服务端 | 服务端端口 + 该客户端地址端口 | 服务端重启时，旧连接的残留挂在服务端口上 |
第二种情况正是“服务停了端口还没放出来”这个说法的来源：服务进程已经退出，但它在退出前主动断开的那些连接，四元组还挂在服务端口这一侧。
这里有一条必须标清楚的边界。服务端主动关闭时，请求方那一侧是否也会进入 TIME-WAIT，属于具体实现的细节，规范只对主动关闭方提了要求。这一点本文没有逐字核到内核实现，标为待验证，不作为结论使用。你如果在自己的环境里观察到两端都有残留，也不必惊讶，先按待验证处理。
5.3 本机实测：临时端口是一个固定区间
上面反复出现“临时端口”这个词，它到底是哪一段？在 macOS 上可以直接问系统。
本机实测（macOS，2026-10-20）：
sysctlnet.inet.ip.portrange.first net.inet.ip.portrange.lastnet.inet.ip.portrange.first: 49152 net.inet.ip.portrange.last: 65535这段区间就是临时端口池：49152 到 65535，首尾都算，一共 16384 个。
再看连接表里的 TIME-WAIT 长什么样。同样是本机实测（macOS，2026-10-20）：
netstat-an-ptcp|grepTIME_WAIT|head-4tcp4 0 0 127.0.0.1.56356 127.0.0.1.9229 TIME_WAIT tcp4 0 0 127.0.0.1.56357 127.0.0.1.9229 TIME_WAIT tcp4 0 0 127.0.0.1.56358 127.0.0.1.9229 TIME_WAIT tcp4 0 0 127.0.0.1.56359 127.0.0.1.9229 TIME_WAIT这四行信息量很大，逐列读一遍：
左侧地址是 127.0.0.1 加一个 56356 起的端口，全部落在 49152–65535 这个区间里——这就是临时端口。右侧是 127.0.0.1 加 9229，四条完全一样——这是被访问的那个服务端口。状态列都是 TIME_WAIT。
结论很直接：这四条记录锁住的是本地临时端口，9229 那个服务端口并没有被锁。服务端口只要能继续监听，新的连接照样进得来。真正被消耗的是临时端口池里的四个名额。
同一份统计里，TIME_WAIT 这一项的计数是 37。这个数字本身说明不了任何问题——37 相对于 16384 的池子，占比很小；而且它是本机某一时刻的快照，下一秒就变了。只有当你看到这个数持续上涨、并且和“新建连接失败”同时出现时，它才值得追。
完整版环境对照表：本文用到的 macOS 与 Linux 在连接表命令、临时端口区间上的差异，我整理成了一张对照表，和本文第五章的观察口径一一对应。放在资料包里，扫码即可获取：
六、两个 socket 选项的差别
6.1 SO_REUSEADDR 管的是“校验时允许复用”
到了这一层，问题从“等多久”变成了“允许不允许”。很多人听说过一个选项叫SO_REUSEADDR，也听说过“设了它就能复用端口”，但这句话省掉了最关键的后半段。
Linux man-pages 的socket(7)对这个选项的原文是：
Indicates that the rules used in validating addresses supplied in a bind(2) call should allow reuse of local addresses. For AF_INET sockets this means that a socket may bind, except when there is an active listening socket bound to the address. When the listening socket is bound to INADDR_ANY with a specific port then it is not possible to bind to this port for any local address.
拆成三层看：
第一层，它改的是校验规则。绑定的时候内核要做一次地址校验，这个选项让校验放宽，允许复用本地地址。
第二层，“except when there is an active listening socket bound to the address”。这句话是硬边界：只要那个地址上还有一个活跃的监听套接字，就绑不上。
第三层，如果监听套接字绑在 INADDR_ANY 加某个具体端口上，那么任何本地地址都绑不到这个端口。
所以必须把话说死：SO_REUSEADDR不是“可以抢占已被监听的端口”。它放宽的是“这个地址刚被用过、还带着残留”这类情形，不是“这个地址现在正有人听着”。这两件事在初学者嘴里经常被合并成一句“开了就能复用”，而恰恰是这半步之差，让很多人在服务真的还在跑的时候，误以为加个选项就能顶上去。
6.2 SO_REUSEPORT 才是“多个套接字绑同一地址”
真正允许“多个套接字绑同一个地址”的是另一个选项。同一份文档里对SO_REUSEPORT（Linux 3.9 起）的原文是：
Permits multiple AF_INET or AF_INET6 sockets to be bound to an identical socket address. This option must be set on each socket (including the first socket) prior to calling bind(2) on the socket. To prevent port hijacking, all of the processes binding to the same address must have the same effective UID.
三个要点：
它才管“同一地址多绑”。这是字面意义上的共用同一个地址和端口。
每一个套接字都要设，包括第一个。这一点常被漏掉：只给后来的套接字设、第一个不设，是不成立的。选项必须在调用绑定之前设好。
同一地址上的所有进程必须有效 UID 相同。原文给的理由是防止端口被劫持（port hijacking）——如果没有这条限制，任何用户都能往别人的服务端口上挂一个套接字分走流量。
6.3 一张对照表，加三个常见误读
| 对比项 | SO_REUSEADDR | SO_REUSEPORT |
|---|---|---|
| 改的是什么 | 绑定时的地址校验规则 | 是否允许多个套接字绑同一地址 |
| 有活跃监听时能否绑上 | 不能 | 能（前提是各方都设了） |
| 设置范围 | 目标套接字 | 每一个套接字，含第一个 |
| 有没有身份限制 | 原文未提 | 有效 UID 必须相同 |
| 常见误读 | “能抢别人的端口” | “设了就会自动分流” |
三个误读，逐个纠正：
误读一：SO_REUSEADDR能抢占正在监听的端口。不能。原文的 except 从句写得明明白白，有活跃监听套接字时绑不上。
误读二：两个选项是一回事，随便设一个。不是。一个放宽校验，一个允许多绑，作用点完全不同。
误读三：SO_REUSEPORT设上就等于负载均衡。原文只说允许多个套接字绑同一地址，没说内核怎么在这些套接字之间分配新连接。分配策略不在本文范围，也不该由这一个选项反推。
理解了这一层，“服务停了端口还没放出来”就有了完整的解释路径：如果 TIME-WAIT 的残留挂在临时端口上，服务端口本身不受影响；如果绑定失败发生在服务端口上，先分清是进程还在，还是选项没设对，而不是一上来就去动系统参数。
七、自查顺序
7.1 五步，每一步只回答一个问题
把前面六章压成一条可执行的路径。每一步只回答一个问题，答完再走下一步，不要跳。
| 步骤 | 问什么 | 看哪里 | 判据 |
|---|---|---|---|
| 一 | 这条连接是谁先关的 | 业务逻辑、抓包、日志时序 | 主动关闭方才可能留下 TIME-WAIT |
| 二 | 残留挂在哪个四元组上 | 连接表 | 左侧端口是临时端口还是服务端口 |
| 三 | 服务端口上还有没有活跃监听 | 连接表里的监听项 | 有活跃监听，SO_REUSEADDR 帮不上 |
| 四 | 进程是否真的退出了 | 进程表 | 进程在，问题不在协议栈 |
| 五 | 选项是在绑定之前设的吗 | 源码里绑定的前几行 | 设晚了等于没设 |
第二步在 Linux 上可以用ss按状态过滤，只看 time-wait，不必把整张表打出来：
⚠️代码待验证
ss-tanstate time-wait第三步要确认某个端口上到底有没有监听。macOS 上用lsof：
⚠️代码待验证
lsof-nP-iTCP:9229-sTCP:LISTEN这两条都是只读观察，不改任何状态。之所以标待验证，是因为它们的效果依赖你机器上的工具版本与权限，本文没有在写稿环境里逐条跑过。
7.2 三个需要改掉的判断习惯
第一个习惯：把 TIME-WAIT 当泄漏。它是有界、自动、局部的等待，不是资源泄漏。看到它先问“这是谁的主动关闭”，而不是“怎么清掉”。
第二个习惯：以为加个选项就能顶上去。SO_REUSEADDR在活跃监听面前无效，SO_REUSEPORT有它自己的前提条件，两个都不能用来“抢”端口。
第三个习惯：把 4 分钟当硬编码。它是规范按 MSL=2 分钟算出来的取值，规范原文自己说了这是工程选择、可以改。所以你在自己环境里量到的数字和 4 分钟不同，是正常的。
7.3 下一步该看哪里
如果你手上正在排查这个问题，按这个顺序看三处就够了：先看连接表的四元组，确认被占的是临时端口还是服务端口；再看那个端口上有没有活跃监听；最后回到代码，确认选项是不是在绑定之前设的。三处看完，问题一定落在其中一处。
至于“要不要动系统参数”这个问题，本文不给答案。它属于运维调优，前提是你已经排除了前三处，而且清楚代价。在没排除之前动参数，等于把症状盖住。
完整版环境对照表：第七章这五步在两套系统上分别该敲哪条命令，对照表里列了同一件事的两种写法，省得你在 macOS 和 Linux 之间来回试。放在资料包里，扫码即可获取：
附表 A：本文引用事实与官方出处对照表
| 编号 | 事实要点 | 出处 | 本文位置 |
|---|---|---|---|
| TW1 | 主动关闭的连接必须在 TIME-WAIT 停留 2×MSL（MUST-13）；TIME-WAIT 下可凭序列号条件接受新 SYN | rfc-editor.org《RFC 9293》第 3.5 节 | 1.2、3.2 |
| TW2 | TIME-WAIT 状态的定义：等够时间以确认对端收到终止确认，并避免新连接受旧连接延迟报文影响 | rfc-editor.org《RFC 9293》第 3.4.2 节 | 2.3、3.1 |
| TW3 | 本规范取 MSL 为 2 分钟，属工程选择，可依经验更改 | rfc-editor.org《RFC 9293》第 3.4.2 节 | 4.2 |
| TW4 | 报文占用的序列号在 MSL 秒内视为占用中 | rfc-editor.org《RFC 9293》第 3.4.3 节 | 2.3、4.3 |
| TW5 | SO_REUSEADDR 放宽地址校验，但有活跃监听套接字时仍不可绑；SO_REUSEPORT 允许多个套接字绑同一地址，需各自设置且有效 UID 相同 | man7.org《socket(7)》Linux man-pages | 6.1、6.2、6.3 |
| TW6 | 本机临时端口区间 49152–65535；TIME-WAIT 记录锁住的是本地临时端口 | 本机实测（macOS，2026-10-20） | 5.3 |
| TW7 | 服务端主动关闭时请求方一侧是否进入 TIME-WAIT、各发行版默认取值 | 未逐字核到，待验证 | 5.2 |
附表 B：术语速查表
| 术语 | 一句话解释 |
|---|---|
| 主动关闭方 | 先发出连接结束请求的那一端，只有它需要停在 TIME-WAIT |
| 被动关闭方 | 收到结束请求后才关闭自己那一端的一方 |
| TIME-WAIT | 主动关闭方在连接结束后的一段等待期，用于兜住丢失的确认与延迟的旧报文 |
| MSL | 报文在网络中存活的最长时间，规范取 2 分钟，是假设值不是测量值 |
| 2×MSL | 规范算出的 TIME-WAIT 停留时长，按 MSL=2 分钟即 4 分钟 |
| 四元组 | 源地址、源端口、目的地址、目的端口，唯一确定一条连接 |
| 临时端口 | 系统分配给对外发起连接的一侧使用的端口区间，本机为 49152–65535 |
| 监听套接字 | 处于监听状态、等待新连接进来的套接字，与已建立的连接不是一回事 |
| SO_REUSEADDR | 放宽绑定时的地址校验，但有活跃监听时仍然绑不上 |
| SO_REUSEPORT | 允许多个套接字绑定同一地址，需各方都设置且有效 UID 相同 |
| 序列号空间 | 每个报文占用的编号区间，在一段时间内视为仍被占用，是 TIME-WAIT 存在的底层理由 |
写在最后：这篇用到的资料
写这篇文章时，我为了确认“被占的到底是哪个端口”，在自己机器上把连接表和临时端口区间都拉出来对了一遍，才发现很多人嘴里的“端口没放出来”，其实和服务端口一点关系都没有。顺手也整理了几份配套的东西：
- 靶场环境对照表：DVWA、upload-labs 在 Windows / macOS / Linux 三平台的可行性与推荐路径
- Web 安全学习路线图：从基础打牢到安全管理，四个阶段各学什么
- 常用靶场清单：每个靶场练什么、适合哪个阶段
资料是我自己整理的，放在下面这个码上，扫码即可获取：
添加时备注「靶场」，优先通过。
拿到之后建议先看环境对照表那一份，把同一件事在两套系统上的写法对齐，下次再遇到“端口没放出来”，先看四元组，别急着动系统参数。
