排查思路，是工具的问题还是window的问题
MobaXterm 报错：Network error: Cannot assign requested address
这个是MobaXterm的报错，不是 VSCode。现象：别的服务器 ssh 正常，唯独172.58.1.251报这个错。
报错含义：客户端（Windows）尝试使用指定的本地源 IP 地址向外建立连接，但该 IP 在本机 Windows 网卡不存在，系统直接拒绝发起连接请求，数据包根本没发到 Linux 服务器。
最高概率原因：MobaXterm 会话配置填写了「Source IP（源地址）」
MobaXterm 新建 SSH 会话的时候，高级设置里面有个选项Advanced SSH settings → Source IP。
- 如果你在这里填过一个本地网卡 IP（比如旧的内网 IP、VPNIP），之后本机网络变化（断开 VPN、换 WiFi、改 IP），这个 IP 不在本机网卡上了，就报这个错误。
- 其他会话没填 SourceIP，所以其他机器连接全部正常，只有这个会话报错，完美匹配你的现象。
✅修复操作：
- 在左侧 Sessions 找到这个
172.58.1.251会话，右键 →Edit session - 点「Advanced SSH settings」标签页
- 把 Source IP 输入框全部清空！不要填写任何本地 IP
- 保存会话，重新连接。
这个 Source IP 等价于 OpenSSH 的
BindAddress参数，强制指定 Windows 本机出口 IP。一旦填写的 IP 失效，直接报Cannot assign requested address。
快速验证（确认是不是会话配置问题）
不使用保存的会话，手动新建临时连接：
- 点左上角
+新建标签，直接在终端输入：
bash
ssh 用户名@172.58.1.251👉 如果手动输入这条命令可以正常连上，100% 确认就是保存会话里面填了无效的Source IP。
其他次要排查点
检查 MobaXterm 代理设置Edit session → Network settings，不要填错误的 Socks/HTTP 代理，代理地址错误也会出现同类报错。
检查 Windows 网卡 IP Windows PowerShell 执行
powershell
ipconfig确认你电脑当前真实 IP，看看会话配置里填的 SourceIP 是否在输出列表中。
- 排除 hosts 解析问题
C:\Windows\System32\drivers\etc\hosts，确认没有把目标主机解析成错误 IP。
❗重要误区
- 不要去改 Linux 服务端 sshd 配置！这个报错请求根本没抵达 Linux。
- 不是 22 端口关闭，端口关闭报错是
Connection refused。 - 不是防火墙拦截，防火墙拦截一般是 timeout。
完整处理流程总结
- 右键该会话 → Edit session → Advanced SSH settings
- 清空 Source IP 输入框（重点！）
- 检查 Network settings 代理，没有代理就保持空白
- 保存会话重连。
很多人以前使用多网卡、VPN 环境，填写过 SourceIP，之后环境变了会话配置没改，就出现只有这一台服务器连不上，其他全部正常。
Source IP藏在Expert SSH settings（专家 SSH 设置）按钮里面！
步骤
- 在当前这个
Advanced SSH settings页面，点击按钮：Expert SSH settings - 弹出窗口里面就有Source IP输入框，检查这里是不是填了 IP 地址。
- 如果里面有 IP，全部清空，确定保存。
如果专家设置里面也是空的，继续排查 Network settings 标签
切换到上方标签Network settings：
- 看有没有配置代理（Socks/HTTP proxy），全部清空，选择
No proxy。
快速验证方法（绕过保存的会话配置）
关闭现有会话，点击 MobaXterm 顶部+，开一个本地 shell 终端，直接在命令行输入：
ssh your_username@172.58.X.X✅ 如果命令行直接 ssh 可以连上，说明问题 100% 出在这个保存的会话书签配置（专家设置 / 网络代理）。 ❌ 如果命令行 ssh 同样报
Cannot assign requested address，那就是 Windows 系统层面问题。
系统层面可能原因（命令行 ssh 也报错）
- Windows 路由表异常，强制指定了无效源 IP 去往
172.58.1.251网段。 PowerShell 执行查看路由：
route print看有没有针对172.58网段的静态路由，绑定了一个本机不存在的源 IP。 2. 网卡 / 虚拟网卡（VPN、WSL、虚拟机网卡）状态异常，禁用多余虚拟网卡测试。
补充：MobaXterm 版本小差异
老版本 MobaXterm 的 Source IP 不在主界面，一定在 Expert SSH settings 弹窗内部，这个是该报错最典型的位置。
操作顺序建议
- 点
Expert SSH settings→ 清空 Source IP，保存会话。 - 切换
Network settings，确认代理 = No proxy。 - 重新打开会话测试。
- 如果依旧报错，新开本地终端，直接敲
ssh user@172.58.1.251，看结果。
当前弹窗（Expert SSH settings）里没有 Source IP，说明这个版本 MobaXterm 把源 IP 参数写在会话主界面，或者这个会话是通过跳板机 / 隧道 (Tunneling)配置的！
看你软件顶部菜单栏有Tunneling按钮！
快速验证第一步（非常关键）
- 关掉这个报错的书签会话；
- 点 MobaXterm 顶部+号，打开本地终端（本地 shell）；
- 直接在命令行敲原生 ssh 连接：
ssh 你的用户名@172.58.1.251- ✅命令行能连上：说明是这个保存书签会话的配置问题（隧道 / 跳板机设置异常）
- ❌命令行同样报 Cannot assign requested address：问题出在 Windows 系统路由、网卡层面，和 MobaXterm 书签无关。
情况 A：命令行 ssh 可以成功（问题在会话书签）
回到该会话编辑界面：
- 切换标签页到Network settings
- 确认代理：选择
No proxy，不要填任何代理地址端口。
- 确认代理：选择
- 看会话最上面：SSH 设置页面，有没有勾选
Connect through SSH gateway (jump host)【跳板机 / 跳转主机】
❗非常高频坑：如果这里填了旧的跳板机 IP，而那个跳板机 IP 现在本机访问不到 / IP 失效，就报一模一样的
Cannot assign requested address，其他会话没开跳板机，所以正常。 👉把Connect through SSH gateway的勾选取消，保存会话重连测试。
你界面顶部就有
Tunneling按钮，也检查是否存在绑定错误本地 IP 的端口转发隧道。
情况 B：本地命令行 ssh 也报同样错误（Windows 系统层面，书签没问题）
Windows 错误码10049:Cannot assign requested address，代表Windows 路由表强制给目标网段指定了一个本机不存在的源 IP。 以管理员打开 PowerShell：
route print查看路由表，检查172.58.1.0/24网段是否有静态路由指定无效Source源地址。
- 如果有异常静态路由，执行删除：
route delete 172.58.1.0然后重新测试 ssh。
额外排查
- 检查 Windows 多余虚拟网卡：VPN 网卡、WSL 网卡、虚拟机网卡，如果有已经断开的 VPN 网卡，禁用掉。
- 检查本机
C:\Users\你的用户名\.ssh\config，是否针对172.58.1.251写了BindAddress。
快速测试方案（绕开旧书签）
直接新建一个完全干净全新 SSH 会话，全部默认设置，不填跳板机，不填代理，只填写 IP 和用户名，尝试连接。
- 新会话可以连上 → 旧书签配置（跳板机 / 隧道）损坏，删掉旧书签，使用新建会话。
- 新会话同样报错 → 系统网络路由层面问题。
这个报错数据包还没发往 Linux 服务器，不要去改 Linux 机器 sshd 配置、防火墙。
建议你先执行本地 shell 直接 ssh 那一步，把结果告诉我，就可以直接定位到底是书签配置还是 Windows 系统路由问题。
结果是Windows 问题
Windows 报错 Cannot assign requested address (Winsock 错误 10049)
现象：不管 MobaXterm 还是原生 ssh 命令行访问172.58.1.251都报这个错；访问其他 IP 正常。
错误含义：Windows 内核尝试用一个本机网卡上不存在的源 IP去发包到目标
172.58.1.251，直接拒绝建立连接，数据包根本没出去。
步骤 1：确认系统选的源 IP 是什么
以管理员打开 PowerShell，执行：
ipconfig # 查询访问目标IP系统会选用什么源地址 Find-NetRoute -RemoteIPAddress 172.58.1.251重点看输出里的SourceAddress。
- 👉 如果输出的
SourceAddress这个 IP，在 ipconfig 全部网卡列表里找不到，就是根因：路由强制绑定了一个已经消失的源 IP（旧 VPN、旧网卡、静态路由残留）。
步骤 2：清理残留静态路由（最高概率）
管理员 PowerShell，打印完整路由表：
route print往下看 IPv4 路由表，找目标网段172.58.1.*相关条目。
删除异常静态路由
# 删除指向172.58.1.0网段的静态路由 route delete 172.58.1.0如果之前有
‑if 接口号或者‑src 源IP的静态路由，删除后系统就会自动选用本机当前有效的网卡 IP 来发包。
执行完删除，再重新查询路由验证：
Find-NetRoute -RemoteIPAddress 172.58.1.251现在SourceAddress应该变成你本机真实网卡 IP。再 ssh 测试。
步骤 3：清理失效虚拟网卡（VPN/WSL/ 虚拟机网卡）
很多时候 VPN 断开，但虚拟网卡设备还残留在 Windows，路由仍然试图走这个已经没有 IP 的网卡。
- Win+R 输入
ncpa.cpl直接打开网卡列表 - 把所有：旧 VPN 网卡、已经不用的虚拟机虚拟网卡、废弃 WSL 网卡，右键禁用（不要删除，禁用即可）
- 只保留你当前真正上网在用的网卡（WiFi / 有线以太网）
- 重新测试 ssh
步骤 4：检查 OpenSSH 用户配置文件（也会强制源 IP）
即使不用 MobaXterm，Windows 自带 OpenSSH 会读取这个文件： 打开文件：C:\Users\<你的windows用户名>\.ssh\config查找是否存在针对该主机的BindAddress配置：
Host 172.58.1.251 BindAddress x.x.x.x #❗这里如果写了一个不存在IP就报10049把BindAddress整行删掉，保存文件。
步骤 5：重置 Windows 网络栈（上面无效再用）
管理员 PowerShell 逐条执行，执行完必须重启电脑：
netsh winsock reset netsh int ip reset作用：重置 winsock、重置 TCP/IP 栈，清除顽固残留网络配置。重启机器后测试 ssh。
排查小技巧：对比正常机器
拿你同一局域网另一台 Windows 机器执行：
Find-NetRoute -RemoteIPAddress 172.58.1.251对比两台机器输出的SourceAddress，正常机器会输出本机真实网卡 IP；故障机器输出一个不存在 IP，就完全确认是本机路由绑定错误。
❗重要提醒
- 不是远端 Linux 机器的问题，数据包没有到达服务器，不要改 Linux 防火墙 /sshd。
- 不是普通防火墙拦截；防火墙拦截报错是连接超时 /connection refused。
常见触发这个故障的历史场景
- 之前连过 VPN 访问 172.58.1.x 网段；VPN 软件卸载 / 断开，但是静态路由没有自动清理，路由还指向 VPN 虚拟网卡。
- 电脑改过网卡静态 IP，旧 IP 的静态路由条目残留在系统中。
操作顺序建议
Find‑NetRoute确认出错的 SourceAddressroute delete删除 172.58.1.0 异常路由- ncpa.cpl 禁用废弃虚拟网卡
- 检查
.ssh/config有无 BindAddress - 仍失败 → winsock+ip reset，重启电脑
如果你把Find‑NetRoute -RemoteIPAddress 172.58.1.251的输出贴出来，我可以直接告诉你是哪条路由出问题。
问题定位
从Find‑NetRoute输出看到一条异常路由：
DestinationPrefix : 172.58.1.250/31 InterfaceAlias : 以太网7 NextHop : 0.0.0.0 Protocol : NetMgmt目标主机是172.58.1.251，正好落在这个
172.58.1.250/31网段内。/31网段包含 2 个 IP：172.58.1.250和172.58.1.251。 Windows 系统强制把去往172.58.1.251的流量交给以太网 7（接口索引 24）。 但以太网 7 网卡上分配的 IP 是 5.5.1.219，这个地址和172.58.1.x不在同一网段。 Windows 试图用5.5.1.219作为源 IP 去访问172.58.1.251，路由规则冲突 → 直接报Cannot assign requested address（Winsock 10049）。
解决（管理员 PowerShell）
1. 删除这条错误的 / 31 静态路由
route delete 172.58.1.250这条路由是根源，它强制把
172.58.1.250‑251流量绑定到 “以太网 7” 网卡。
2. 删除完再验证路由选择
Find-NetRoute -RemoteIPAddress 172.58.1.251✅现在输出应该走你正常访问内网的网卡，不再指向以太网 7。
3. 测试 ssh
ssh 用户名@172.58.1.251如果 route delete 提示找不到元素
用 netsh 方式按前缀删除：
netsh interface ipv4 delete route 172.58.1.250/31补充说明
- 这条路由来源：大概率是之前 VPN 软件、虚拟化软件、某些安全代理工具自动写入，卸载 / 断开后路由残留。
- 不要修改 Linux 服务器任何配置，故障完全发生在 Windows 本机路由表。
善后检查
执行完删除后，ipconfig看一下 “以太网 7”：IP=5.5.1.219，如果这个网卡本身已经不需要，可以打开ncpa.cpl把 “以太网 7” 直接禁用，避免以后再次出现同类问题。
