AIGC:
    Label: "1"
    ContentProducer: 001191110102MACQD9K64018705
    ProduceID: 687608750681449_0/project_7672303624038433033-files/SSH连接排障记录-网线直连踩坑全记录.md
    ReservedCode1: ""
    ContentPropagator: 001191110102MACQD9K64028705
    PropagateID: 687608750681449#1786428820538
    ReservedCode2: ""

一次 SSH 连接排障全记录：为什么一根网线能折腾一下午

摘要：服务器和电脑明明都配了 IP，ping 也"通"了，但 SSH 就是连不上。本文记录了一次从 IP 冲突、子网掩码不匹配、双网口混淆到最终发现交换机 VLAN 隔离的完整排障过程。每一关看似都解决了，但下一关才真正暴露出来。

一、问题描述

我有一台 Linux 服务器，通过网线直连 Windows 电脑，想用 SSH 客户端连上去。

配置完之后，ping 能通，但 SSH 报 Connection refused：

Network error: Connection refused
Session stopped

看起来是个简单问题，结果从下午三点折腾到天黑。

二、服务器环境

服务器是 Linux 系统，背面有 4 个物理网口：

端口标识 说明
Mgmt 管理口（未使用）
Port-A 共享网口（未使用）
Port-B 物理网口 1，插了黑色网线
Port-C 空着
Port-D 物理网口 2，插了蓝色网线（我用的这个）

系统中有两个物理网卡接口（通过 ip addr 查看）：

[root@server ~]# ip addr

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
    inet 10.20.1.11/20 brd 10.20.15.255 scope global eth0
    # 对应 Port-B（黑色线）

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
    inet 172.16.5.63/24 brd 172.16.5.255 scope global eth1
    # 对应 Port-D（蓝色线）

另外还有一个 virbr0（虚拟网桥）和 docker0（Docker 虚拟网桥），跟本次问题无关。

SSH 服务确认正常运行：

[root@server ~]# ss -tulnp | grep sshd
tcp   LISTEN  0  128  0.0.0.0:22  0.0.0.0:*  users:(("sshd",pid=1234,fd=3))
tcp   LISTEN  0  128  [::]:22     [::]:*     users:(("sshd",pid=1234,fd=4))

[root@server ~]# firewall-cmd --list-services
dhcpv6-client mdns ssh    # SSH 已放行

[root@server ~]# grep PermitRootLogin /etc/ssh/sshd_config
PermitRootLogin yes

防火墙没有拒绝规则，SSH 监听在 0.0.0.0:22，PermitRootLogin 也开了。 服务端一切正常。

三、Windows 环境

以太网适配器 以太网:
  描述: Realtek PCIe GbE Family Controller
  物理地址: AA-BB-CC-DD-EE-01
  IPv4 地址: 172.16.5.100（手动配置）
  子网掩码: 255.255.255.0
  DHCP: 否

无线局域网适配器 WLAN:
  IPv4 地址: 10.50.38.200
  子网掩码: 255.255.255.0

以太网适配器 VMware Network Adapter VMnet1:
  IPv4 地址: 192.168.202.1

以太网适配器 VMware Network Adapter VMnet8:
  IPv4 地址: 192.168.40.1

注意：电脑同时有 4 个活跃网卡（以太网 + WiFi + VMnet1 + VMnet8），这在后续排障中制造了不少麻烦。

四、排障过程

第一关：IP 冲突 — ping 通的可能是自己

症状

服务器配了 10.20.1.11，Windows 也配了 10.20.1.11。ping 能通，但 SSH 连不上。

C:\> ping 10.20.1.11

正在 Ping 10.20.1.11 具有 32 字节的数据:
来自 10.20.1.11 的回复: 字节=32 时间<1ms TTL=128
来自 10.20.1.11 的回复: 字节=32 时间<1ms TTL=128
分析

ping 能通，说明网络层是通的。但 SSH 报 Connection refused，说明目标机器上没有 SSH 服务在监听。

关键线索是 TTL=128。Linux 系统默认的 TTL 通常是 64，而 Windows 默认的 TTL 是 128。这意味着 ping 回来的包不是从 Linux 服务器回来的，而是从 Windows 自己回来的。

两台机器配了同一个 IP，ARP 解析会同时收到两个 MAC 地址的回应，谁先响应就连谁。这里 Windows 自己响应了自己的 ARP 请求，所以 ping 通的是自己。

解决

把 Windows 的 IP 改成不同的地址：172.16.5.100。

教训

ping 通不代表连的是目标机器。 看 TTL 值（Linux 通常 64，Windows 通常 128）可以判断 ping 到的是谁。两台机器同 IP 时，ARP 解析会随机指向其中一个。

第二关：子网掩码不匹配

症状

Windows 改成 172.16.5.100，但子网掩码一开始设的是 255.255.255.0（/24）。服务器的 eth1 配置的是 /20（255.255.240.0）。

[root@server ~]# ip addr show eth1
    inet 10.20.1.11/20 brd 10.20.15.255 scope global eth1
分析

掩码不一致会导致两端对"同一个子网"的判断不同：

  • Windows（/24）：认为 172.16.5.0/24 是本地子网，只会给这个范围内的 IP 发 ARP
  • 服务器（/20）：认为 10.20.0.0/20 是本地子网

两边根本不在同一个网段，自然不会互相通信。

解决

把 Windows 的掩码改成 255.255.240.0（/20），让两端在同一子网。后来发现掩码虽然对了，但 IP 段仍然不对——因为服务器的 eth1 实际配的是 172.16.5.63/24，不是 10.20.1.11/20。最终决定用 172.16.5.x 网段：

  • 服务器：172.16.5.63/24（eth1）
  • Windows：172.16.5.100/24
教训

子网掩码必须一致。 改 IP 之前先确认两端的网段和掩码完全匹配。用 ip addr（Linux）和 ipconfig（Windows）仔细核对。

第三关：双网口，分不清线插在哪

症状

服务器背面 Port-B 和 Port-D 都插了线，ethtool 显示两个口都 Link detected: yes：

[root@server ~]# ethtool eth0 | grep Link
    Link detected: yes

[root@server ~]# ethtool eth1 | grep Link
    Link detected: yes

根本分不清我的线在 Port-B 还是 Port-D，也不确定 eth1 对应哪个物理口。

分析

Link detected: yes 只表示网口检测到了物理链路（link up），不代表你的线就插在这个口上。服务器有 4 个口，其中 Port-A、Port-B、Port-D 都有线，任何一根线都可能对应任何一个 Linux 网卡接口。
在这里插入图片描述

尝试的排查方法
  1. 看端口标注：服务器背面 Mgmt、Port-A、Port-B、Port-C、Port-D 有标注，但 Linux 内核命名（eth0、eth1）和物理标注的对应关系需要实际验证。
  2. 拔线测试：拔掉某根线，看哪个网卡 Link detected 变成 no。
  3. tcpdump 抓包：在 Windows 上持续 ping，在服务器上对两个网卡分别抓包，看哪个口能收到 ICMP 包。
教训

Link detected: yes ≠ 你的线在这个口。 要确认端口映射，必须用拔线测试或 tcpdump 抓包来验证。服务器背面的物理端口标注和 Linux 内核的网卡命名不是一一对应的，需要实测。

第四关：交换机 VLAN 隔离（真正的坑）

症状

IP 配置确认正确（Windows: 172.16.5.100/24，服务器 eth1: 172.16.5.63/24），但 ping 报的不再是"请求超时"，而是：

C:\> ping -S 172.16.5.100 172.16.5.63

正在 Ping 172.16.5.63 从 172.16.5.100 具有 32 字节的数据:
来自 172.16.5.100 的回复: 无法访问目标主机。
来自 172.16.5.100 的回复: 无法访问目标主机。

注意：不是"请求超时"（Request timed out），而是"无法访问目标主机"（Destination host unreachable）。 这两个错误含义完全不同。

深入分析

“无法访问目标主机” 是 Windows 本地返回的错误，含义是：ARP 广播发出去了，但没有收到任何 ARP 回复，MAC 地址解析失败。Windows 连包都发不出去，更别提 ICMP 了。

“请求超时” 则是：ARP 成功了（知道对方 MAC），ICMP 包也发出去了，但对方没有回复。

用 arp -a 验证：

C:\> arp -a

接口: 172.16.5.100 --- 0xc
  Internet 地址         物理地址              类型
  172.16.5.255          ff-ff-ff-ff-ff-ff     静态
  224.0.0.22            01-00-5e-00-00-16     静态
  ...
  # 注意：没有 172.16.5.63 的条目！

ARP 完全失败。 在服务器端也验证：

[root@server ~]# ip neigh show
172.16.5.100 dev eth1 FAILED    # 服务器也解析不到 Windows 的 MAC
172.16.5.63 dev eth1 lladdr ... REACHABLE    # 自己（本地接口）

双向 ARP 都失败。 说明数据包在二层（数据链路层）根本没到对方。

关键证据：tcpdump 抓包

在服务器上对 eth1 抓包：

[root@server ~]# sudo tcpdump -i eth1 -n -c 500

抓到的不是来自 172.16.5.100 的包，而是：

14:32:05.123456 ARP, Request who-has 172.16.8.233 tell 172.16.8.1
14:32:05.234567 ARP, Reply 172.16.8.233 is-at aa:bb:cc:dd:ee:ff
14:32:05.345678 STP 802.1s, Rapid STP, CIST Flags [Learn, Forward, Agreement]
14:32:05.456789 STP 802.1s, Rapid STP, CIST Flags [Learn, Forward]
14:32:06.567890 DHCP, Request from aa:bb:cc:dd:ee:ff
14:32:06.678901 mDNS from 172.16.5.1
...

三个关键发现：

  1. STP（802.1s Rapid STP）包：这是管理型交换机才会发的协议。说明 eth1 连到的不是一个直接的设备，而是一个交换机网络。
  2. 172.16.8.233 的 ARP：这个 IP 和我们的 172.16.5.x 不在同一网段，说明交换机上还有其他 VLAN 的设备。
  3. 完全没有 172.16.5.100 的任何包：Windows 发出的 ARP 广播根本没有到达服务器的 eth1 口。
根因定位

服务器的 Port-A、Port-B 连着的线通向楼层的管理型交换机，交换机之间运行着 STP 协议。Port-D 虽然插着我的线，但这根线并不是真正直连到 Port-D 的物理端口——它经过了墙上面板 → 配线架 → 楼层交换机 → 再回到服务器的 Port-D 口。

交换机的端口划分了不同的 VLAN：

  • 服务器 Port-A/Port-B 对应的端口在 VLAN X
  • 我的 Windows 对应的端口在 VLAN Y
  • 两个 VLAN 在二层完全隔离，ARP 广播无法跨 VLAN 传播

所以：物理链路是通的（Link detected: yes），Windows 也显示"未识别的网络"（link up），但二层数据包被 VLAN 隔断了，ARP 请求永远到不了对方。
在这里插入图片描述

教训

"直连"和"插在同一台服务器上"是两回事。 如果网线经过了交换机，VLAN 隔离会让两台机器在二层完全不通信。Link detected: yes 只说明物理层链路通，不代表数据链路层（L2）能通信。tcpdump 是排障的终极武器 — 抓不到对方的包，就一定是物理层或二层的问题。

五、最终解决

在服务器上拔掉 Port-D 的蓝色网线，拿一根新网线，一头直接插服务器的 Port-D 口，另一头直接插 Windows 的 RJ45 网口。中间不经过任何交换机、墙上面板或配线架。

重新 ping：

C:\> ping 172.16.5.63

正在 Ping 172.16.5.63 具有 32 字节的数据:
来自 172.16.5.63 的回复: 字节=32 时间<1ms TTL=64
来自 172.16.5.63 的回复: 字节=32 时间<1ms TTL=64

TTL=64，Linux 服务器！ 这次 ping 到的是真正的目标机器。

[root@server ~]# ip neigh show
172.16.5.100 dev eth1 lladdr AA-BB-CC-DD-EE-01 REACHABLE    # Windows MAC 已解析

打开 SSH 客户端，连接 172.16.5.63：

login as: root
root@172.16.5.63's password:
Last login: Tue Aug 11 13:45:22 2026 from 172.16.5.100

成功了。

六、复盘总结

为什么花了这么久

整个过程经历了四轮排障，每一轮解决后才暴露下一轮的问题：

轮次 问题 表面症状 实际根因 耗时
1 IP 冲突 ping 通但 SSH refused 两台机器同 IP，ping 到自己 ~30min
2 掩码/网段不匹配 ping 超时 跨网段切换时配置反复出错 ~20min
3 双网口混淆 链路通但不通信 不确定线插在哪个物理口 ~15min
4 交换机 VLAN 隔离 ARP 完全失败 网线经过交换机，VLAN 隔离 ~2h

最容易误导人的现象

  1. "ping 能通"≠ 网络正常 — IP 冲突时 ping 的是自己（TTL=128）
  2. "Link detected: yes"≠ 网络通了 — 物理层通不代表二层通
  3. "未识别的网络"≠ 网线没插好 — 这其实说明 link up 了，只是没有 DHCP/网关
  4. "无法访问目标主机"≠ 对方防火墙拦截 — 这是 ARP 失败，比防火墙更底层

排障思路总结

遇到网络不通时，按 OSI 七层模型从底向上排查：

第1层 物理层    → 网线插对了吗？灯亮了吗？ethtool Link detected？
第2层 数据链路层 → MAC 能解析吗？arp -a / ip neigh show 有对端条目吗？
第3层 网络层    → IP 在同一子网吗？掩码一致吗？路由对吗？
第4层 传输层    → 端口在监听吗？ss -tulnp / netstat -tlnp
第7层 应用层    → SSH 服务跑了吗？配置对吗？日志有报错吗？

每一层不通，上面所有的检查都没有意义。 必须先确保底层通了，再查上层。

在这里插入图片描述

七、关键排障命令备忘

服务器端（Linux）

# 查看网卡 IP、掩码、状态
ip addr

# 查看物理链路状态
ethtool <网卡名>

# 抓包 — 排障终极武器
sudo tcpdump -i <网卡名> -n          # 抓所有包
sudo tcpdump -i <网卡名> arp -n      # 只抓 ARP
sudo tcpdump -i <网卡名> icmp -c 5   # 只抓 ICMP，抓5个就停

# 查看 ARP 表（二层是否通）
ip neigh show

# 防火墙 SSH 是否放行
firewall-cmd --list-services

# SSH 服务日志（是否有过成功/失败连接）
grep sshd /var/log/secure | tail -20

# SSH 服务是否运行
ss -tulnp | grep sshd
systemctl status sshd

Windows 端

:: 查看所有网卡状态和 IP
ipconfig /all

:: 指定源 IP ping（排除多网卡路由干扰）
ping -S <本机IP> <目标IP>

:: 查看 ARP 表
arp -a

:: 持续 ping
ping -t <目标IP>

:: 查看路由表
route print

:: 临时关闭 Windows 防火墙（测试完记得开回来）
netsh advfirewall set allprofiles state off
netsh advfirewall set allprofiles state on

八、一句话总结

“物理链路通"不等于"网络层通”。 网线经过交换机时，VLAN 隔离可以在二层完全切断通信，而所有物理层的指示灯都告诉你"一切正常"。最可靠的直连，就是一根线从 A 到 B，中间什么都没有。遇到问题时，tcpdump 抓包是排障的终极武器 — 抓不到对方的包，就一定是底层的问题，不要在上层浪费时间。

链接

Linux 侧工具文档

https://www.tcpdump.org/manpages/tcpdump.1.html （tcpdump 手册）
https://man7.org/linux/man-pages/man8/ethtool.8.html （ethtool 手册）
https://man7.org/linux/man-pages/man8/ip-address.8.html （ip addr 手册）
https://man7.org/linux/man-pages/man8/ip-neighbour.8.html （ip neigh / ARP 表手册）
https://man.openbsd.org/sshd_config （sshd_config 配置手册）
https://firewalld.org/documentation/ （firewalld 官方文档）
Windows 侧命令文档 7. https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ping （ping） 8. https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/arp （arp） 9. https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ipconfig （ipconfig） 10. https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/netsh-advfirewall-firewall-control-firewall-behavior （netsh advfirewall 防火墙开关）

协议标准 11. https://www.rfc-editor.org/rfc/rfc826 （RFC 826 · ARP 协议） 12. https://www.rfc-editor.org/rfc/rfc792 （RFC 792 · ICMP 协议） 13. https://1.ieee802.org/tsn/802-1q/ （IEEE 802.1Q · VLAN / 生成树标准）

# ssh # 运维
Logo
DAMO开发者矩阵

DAMO开发者矩阵，由阿里巴巴达摩院和中国互联网协会联合发起，致力于探讨最前沿的技术趋势与应用成果，搭建高质量的交流与分享平台，推动技术创新与产业应用链接，围绕“人工智能与新型计算”构建开放共享的开发者生态。

更多推荐

cover

LemoSenti三维具身智能交互

avatar DAMO开发者矩阵

02-VLA模型深度解析

VLA 之所以被称为具身智能的"范式革命"，是因为它从根本上改变了机器人智能的实现方式。我们用一个对比来直观感受。维度传统模块化方案VLA 端到端方案架构感知→规划→控制，多模块接力一个模型端到端泛化能力弱，新场景需重新调参强，零样本/少样本泛化可解释性强，每个模块可独立分析弱，黑盒模型安全性易保证，可在规划层设硬约束难保证，需额外安全层实时性好，模块轻量、延迟低挑战，大模型推理慢开发成本高，需多

avatar DAMO开发者矩阵
cover

宇树上市刷屏，人形机器人传感器怎么选？我用数字FAE拆给你看

avatar DAMO开发者矩阵