ARP 问题诊断：为什么 ping 正常，TCP 却时通时断

服务扩容后，新虚拟机的 TCP 端口有时能连接，有时立即被拒绝。运维人员连续 ping，却没有看到丢包。这样的现象很容易让排查停在“网络正常，检查应用”上，但 ICMP 能得到回应，只能证明有人回答了这个 IP，不能证明每次都到达了预期的服务器。

本文将 laixintao 在“卡瓦邦噶！”发表的两篇文章合并整理：2026 年 2 月 25 日的题目《网络断断续续……》，以及 2026 年 3 月 1 日的解析《ARP 问题诊断》。两篇属于“抓包破案录”，是作者根据工作经历重新构造的教学案例。本文经过授权整理，保留题目、分析过程、命令输出与结论；没有重新解析所附 PCAP，也没有在任何网络上运行探测命令。

题目：新虚拟机的 9999 端口为什么偶发被拒绝

扩容出来的虚拟机地址是 10.210.151.90。业务团队测试 TCP 9999 端口，看到类似结果：

$ nc -vz 10.210.151.90 9999
nc: connect to 10.210.151.90 port 9999 (tcp) failed: Connection refused
$ nc -vz 10.210.151.90 9999
nc: connect to 10.210.151.90 port 9999 (tcp) failed: Connection refused
$ nc -vz 10.210.151.90 9999
Connection to 10.210.151.90 9999 port [tcp/*] succeeded!

负责虚拟机的同事检查 ping，发现没有丢包，于是认为问题出在业务服务。业务方仍然无法稳定使用端口。题目安排读者扮演熟悉网络分析的同事：一边做 ping 与 TCP 连接测试，一边抓包，回答连接为什么时成时败。

读者可以从原题取得tcp-connect-issue.pcap 抓包压缩包。它是原作者提供的练习资料；本文未解压解析或为其生成新的逐包结论。以下命令和输出均来自原文，若在自己的网络复现，必须限定在有权限的主机与网段。

先比较成功与失败的连接

碰到时好时坏的问题，没有明确假设时，可以先选出一组成功记录、一组失败记录，把它们逐层对照。并不保证每个故障都能在客户端抓包里找到根因：若报文完全相同，问题也可能在中间设备或对端。但这个练习的线索就在抓包中。

原文展示的正常连接能完成 TCP 握手和挥手；异常连接发出 SYN 后直接收到 RST。关键差异不在目标 IP 或目标端口，而在发出 SYN 时的二层目的 MAC。成功与失败的 SYN 使用了不同的 Dst MAC。

原文还用 Wireshark 的 Statistics → Conversations 对照会话：通信的 IP 对只有一对，但 MAC 对出现两对。这个对比把问题从“同一台服务器上的应用不稳定”引向了“同一个 IP 的报文可能交给不同的二层接收者”。

再核对报文到底应交给谁

原文给出的源 IP 是 10.210.151.187，目标 IP 是 10.210.151.90。这两个地址看起来可能在同一个 /24 子网，但仅看地址不能确认掩码，仍要查看主机的真实地址与路由配置。

若二者确实在同一链路子网，源主机直接向目标主机发送以太网帧，目的 MAC 应来自目标 IP 的邻居解析。若路由选择了网关，IP 包的目的 IP 仍是远端目标，但当前这一跳的以太网目的 MAC 是下一跳网关。不能把“TCP 包目的地址”与“承载它的帧目的 MAC”混成一个字段。

在这个给定练习中，正常与异常流量的 MAC 差异支持原作者的答案：同一子网里的两台独立设备被分配了相同的 10.210.151.90。真实环境里，看到多个 MAC 仍应进一步排除合法的高可用切换、共享地址、代理 ARP，以及路由变化等情况；不能把“IP 对一组、MAC 对两组”当成适用于所有网络的充分判据。

重复 IP 如何让连接碰运气

同链路通信前，发送端需要取得对方的 MAC；若邻居表中没有可用映射，通常通过 ARP 广播询问谁持有目标 IP。现在两台机器都认为自己拥有这个 IP，却各有不同的 MAC，它们都会回应询问。发送端选择或更新的邻居映射因此可能指向不同设备。

原文通过另一组 arping 演示输出说明双应答。这里保留其 MAC、计数与延迟值，它们是原作者给出的示例，并非本文测量：

$ arping -c 3 10.210.151.90
ARPING 10.210.151.90
42 bytes from 5a:65:98:0c:82:02 (10.210.151.90): index=0 time=944.055 usec
42 bytes from c2:10:70:f2:ae:ab (10.210.151.90): index=1 time=997.915 usec
42 bytes from 5a:65:98:0c:82:02 (10.210.151.90): index=2 time=13.799 usec
42 bytes from c2:10:70:f2:ae:ab (10.210.151.90): index=3 time=109.388 usec
42 bytes from 5a:65:98:0c:82:02 (10.210.151.90): index=4 time=6.670 usec
42 bytes from c2:10:70:f2:ae:ab (10.210.151.90): index=5 time=48.983 usec

--- 10.210.151.90 statistics ---
3 packets transmitted, 6 packets received, 0% unanswered (3 extra)
rtt min/avg/max/std-dev = 0.007/0.353/0.998/0.438 ms

发送三次询问，收到六个应答，每次都有两个 MAC 声称拥有同一 IP。这比先从大量 TCP 包中筛选差异更直接。作者也说明，如果只是快速验证疑似地址冲突，arping 往往更方便；这里采用抓包，是为了练习分析方法。

原文 Wireshark 截图与这一段 arping 输出中的 MAC 并不是同一组，应该视为两个用于解释相同机制的演示材料，不能拼接成一份逐包一致的原始现场记录。本文没有由这些片段推断硬件厂商或完整拓扑。

“先收到的 ARP 应答为准”需要限定条件

原文用“先收到的应答”解释映射为何在两个设备之间变化，并给出邻居表样例：

$ ip nei show
10.210.151.90 dev h2-eth0 lladdr 5a:65:98:0c:82:02 REACHABLE

ARP 请求出去后，两台设备回复的先后可能变化，于是同一个 IP 的后续流量可能交给不同 MAC。这个解释能帮助理解教学场景，但不应扩大为所有操作系统、所有缓存状态、所有 ARP 报文都永远采用“第一条回复”。

为核对这一边界，本文静态查阅了 Linux 6.12 的 net/ipv4/arp.c。在处理连续应答的代码附近，是否允许覆盖邻居映射还取决于 LOCKTIME 时间窗口与 gratuitous ARP 条件。源码注释确实说明优先使用紧接着到来的第一条回复，但实现保留了这些条件。因此这里只将 Linux 6.12 作为说明边界的参考，并不倒推练习使用了这个内核版本。

去真正的服务端抓包，检查它有没有参与失败连接

客户端收到 Connection refused，通常表示收到 RST，但 RST 不一定来自期望中的服务器，也可能来自其他设备。原作者建议到真正的对端同步抓包：它是否收到 SYN？它是否发送了这条 RST？

如果客户端明确收到了 RST，而预期的服务器既没收到对应 SYN，也没发出 RST，就说明这一轮通信没有按预期到达它。结合 MAC 差异和 ARP 双应答，就能沿交换机端口、虚拟机配置或设备资产记录寻找另一个占用地址的对象。

这一步比只凭应用日志推测更有区分度。真正服务器上没有错误日志，可能不是应用运行良好，而是问题请求根本没有到过它。抓包也应选择正确接口与时间窗口，否则“没有看到”不能直接等于“没有发生”。

为什么 ping 一直正常

这两台设备都配置了相同的 IP，也都能回应 ICMP Echo。ping 只看到请求得到了匹配的回应，并不了解业务本来期望的是哪台服务器。因此无论报文落到哪一台，ping 都可能成功。

TCP 9999 端口的情况不同：预期服务器提供服务，另一台设备没有相同监听状态，收到 SYN 后可能返回 RST。于是 ICMP 测试稳定，TCP 测试却取决于这一轮报文被送到了谁。ICMP 成功不是 TCP 服务可用的充分条件，更不是目标身份唯一的证明。

原文建议在 Wireshark 列表中加入 Src MAC 列，观察 ping 回复的来源。虽然 IP 地址不变，回应帧的源 MAC 却可以来自不同设备。把二层字段放到日常分析视野里，就不容易被“同一个 IP、零丢包”遮住线索。

查完机制，还要核对地址分配记录

为什么会出现重复地址？作者给出的管理背景是：办公或家庭终端常通过 DHCP 动态获取地址，而其讨论的 IDC 场景倾向于固定地址，并由 IPAM 记录分配。若某个地址已经使用却没有登记，后续分配就可能把同一个地址给另一台设备。

这是原文对本类问题的解释，不是所有数据中心都不用 DHCP 的通用规则。原文也没有展示完整 IPAM 系统、全部资产记录或修复后的连续观测，所以不能声称本文已独立验证了某个生产地址分配系统的具体缺陷。

实际处理时，应在确认设备归属后由获授权的管理员修正地址配置或分配记录，再复查邻居映射、TCP 连接和实际业务请求是否稳定。仅临时清空 ARP 缓存，即使短时间让连接恢复，也不会消除两个设备同时占用同一地址的根因。本文没有提供或执行批量改地址、清邻居表或停机操作。

这个案例的价值在于逐步缩小事实范围：先承认 ping 与 TCP 可以给出不同结果，再对照成功与失败连接，把 IP、MAC、ARP 和对端抓包放在同一条证据链中。最终结论应来自实际配置与观测，而不是把任何一种单独的网络测试当成整个系统的健康证明。

作者与许可：laixintao，卡瓦邦噶！。两原页标注 CC BY-NC-ND 4.0。该公共许可本身不授权改编或商业转载；保留原作者、两篇来源、日期与原许可线索。配图为本文原创示意图，不冒充原作者抓包截图。