企业官网建设流程全解析

这块板子前两天还在正常跑，今天在 Uboot 里敲下ping 192.168.1.100，回显却是ping failed; host 192.168.1.100 is not alive。更让人头大的是，同一根网线插到笔记本上能通，插到 PC 上也大概率能通，一换成 VMware 或者 VirtualBox 里的虚拟机，Uboot 就装死。Uboot ping 不通 PC 机或虚拟机，本质上不是一句“网络不通”能概括的，它横跨 MAC、PHY、设备树、时钟、环境变量、防火墙、虚拟网卡桥接模式这几层。只要中间任意一层掉链子，现象都长得很像。下面我按实际排障顺序，把这套问题拆开讲清楚，适合正在移植 Uboot、调 RK3568、IMX6ULL、FMQL 千兆网，或者刚装完虚拟机准备联调板子的人参考。

1. 先搞清楚 Uboot 里的 ping 到底在干什么

1.1 Uboot 网络协议栈比 Linux 小很多，别用 Linux 经验硬套

Uboot 下的网络功能一直是个“够用就行”的状态。它没有 Linux 那么完整的网络栈，也没有 systemd、NetworkManager、netplan 这些帮你兜底的东西。Uboot 里通常只有最基础的以太网驱动、ARP、ICMP、TFTP、DHCP 等少量协议。ping命令能跑起来，说明编译时已经打开了CONFIG_CMD_PING、CONFIG_CMD_NET、CONFIG_NET之类的选项，并且当前有可用的网络设备。但“命令存在”不等于“链路可用”，更不等于“对端会回你”。

在 Uboot 里执行ping，大致会走这么几步：先确认当前选中的网口，然后检查 PHY 链路是否 up，接着发 ARP 请求询问目标 IP 的 MAC 地址，收到 ARP 回复后再发 ICMP Echo Request，最后等 ICMP Echo Reply。很多人的板子卡在第一步或者第二步，也就是 PHY 链路根本没起来。也有人能打印出 link up，但 ARP 永远收不到回复。还有人 ARP 通了，ICMP 被对端防火墙吞掉，于是 Uboot 只会告诉你目标不 alive。

Uboot 的网络设备命名和 Linux 不一样。你可能会看到eth0、eth1，也可能看到gmac0、fec0。哪个口是当前活动口，可以用bdinfo、printenv、ethact之类的环境变量确认。有些板子默认ethact指向了错误网口，比如你插的是千兆口，它却拿另一个没接网线的口去 ping，结果自然失败。遇到多网口板子，先用ethact切到正确设备，或者用setenv ethact gmac0再试。

提示：Uboot 下不要指望ifconfig、ip addr、ethtool这些 Linux 命令。大多数 Uboot 只支持ping、tftp、dhcp、mii、mdio、setenv、printenv。先确认命令集，再谈排查。

1.2 ping 成功的最小必要条件：一条链上不能有断点

Uboot ping 通 PC 或虚拟机，最少要同时满足这些条件。板子 MAC 控制器已经初始化，PHY 已经上电、复位完成、地址识别正确，MAC 和 PHY 之间的接口模式与时钟方向匹配，PHY 和对端网卡完成自协商，链路状态为 up。Uboot 侧ipaddr与对端 IP 在同一网段，netmask没写错，ethaddr不是全 0 或全 F。对端网卡处于同一广播域，中间没有路由器隔断，ARP 能广播到。对端系统允许 ICMP Echo Request 入站，或者至少没有把 ARP 和 ICMP 全部拦掉。如果用了虚拟机，还要虚拟机网络模式允许板子的广播包进入虚拟机。

只要其中一个条件不成立，ping就会失败。问题在于 Uboot 报错信息非常贫乏。它不会告诉你“PHY 没起来”，也不会告诉你“ARP 没收到回复”。它只会给一个统一失败结果。因此排查时必须自己把链路切开，一段一段确认。我的习惯是先看 PHY 链路，再看 ARP，最后看 ICMP。顺序不要乱，否则很容易在应用层瞎改，浪费一整天。

1.3 为什么 PC 能通，虚拟机却经常不通

PC 能通、虚拟机不通，这个现象太常见了。原因通常不在 Uboot，而在虚拟机的网络模式。虚拟机默认常用 NAT 模式。NAT 模式下，虚拟机躲在主机后面，外面设备不能直接访问虚拟机的私有 IP。Uboot 发的 ARP 广播到不了虚拟机，虚拟机也不知道板子的 IP 对应哪个 MAC。你可能会想“那我用端口转发”，但 ICMP 不是 TCP/UDP，端口转发通常不适用于普通 ping，很多虚拟化工具也不给你转 ICMP。

另一种常见情况是虚拟机用了“仅主机模式”。这个模式只让主机和虚拟机通信，板子不在这个虚拟网络里。除非你把板子网线接到主机某个物理网卡，并且把这个物理网卡也桥进仅主机网络，否则 Uboot 永远 ping 不到虚拟机。还有一种是桥接模式选错了物理网卡。主机有 WiFi 和有线网卡，虚拟机自动桥接到了 WiFi，而板子插在有线网卡上。两个网络不在同一广播域，当然不通。

虚拟机网络适配器本身也可能有问题。Windows 里 VMware 的 VMnet1 或 VMnet8 出现感叹号，虚拟网卡驱动没装好，或者网卡被禁用，都会导致虚拟机没有可用网络。Ubuntu 虚拟机里ip addr只有lo，那就别急着怪 Uboot。先让虚拟机自己拿到同网段 IP，能 ping 通主机，再让 Uboot 来 ping 它。这个顺序很重要。

2. 硬件链路与设备树：多数故障在这里

2.1 接口模式与时钟方向：RGMII、RMII 不是随便填的

MAC 和 PHY 之间的接口模式，是 Uboot 网络不通的高频原因。RK3568、IMX6ULL、FMQL 这些平台常见 RGMII、RMII、MII。模式不对，轻则百兆能通千兆不通，重则完全没链路。RGMII 又分rgmii、rgmii-id、rgmii-txid、rgmii-rxid。这些后缀决定延迟加在 MAC 侧还是 PHY 侧。很多原理图里 PHY 默认不加内部延迟，设备树就必须写rgmii-id让 MAC 补延迟。如果写成了普通rgmii，链路可能显示 up，但 ARP 丢包，ping 不通。

时钟方向也要注意。RGMII 的 TXC 和 RXC 由谁提供，PHY 还是 MAC，必须和硬件设计一致。有些板子 PHY 输出 125MHz 时钟给 MAC，有些是 MAC 输出。设备树里的assigned-clock、clock-names、tx_delay、rx_delay都可能影响。IMX6ULL 的 FEC 控制器经常用phy-mode = "rmii"，但 RMII 还需要 50MHz 参考时钟。如果时钟源没使能，PHY 可能被识别，但数据发不出去。

RK3568 的 GMAC 节点里常见phy-mode = "rgmii-id"，同时还要配snps,reset-gpio、snps,reset-active-low、snps,reset-delays-us。这些复位参数不对，PHY 上电后可能没被正确复位。你会在mdio list里看不到 PHY，或者看到地址但寄存器读出来全是0xffff。FMQL 千兆网不通时，也要优先看这些接口模式、延迟、复位、时钟，而不是一上来就改驱动。

2.2 PHY 地址、复位、供电和 MDIO 扫描

PHY 地址由硬件 strapping 电阻决定，一般是 0 到 31。设备树里reg = <0>表示 PHY 地址 0。如果硬件实际是地址 1，设备树写 0，Uboot 就找不到 PHY。表现是mdio list没有输出，或者网络设备初始化失败。你可以用mdio list扫描总线，看能不能列出 PHY。能列出地址后，再读 PHY ID 寄存器，确认是不是你原理图上的那颗 PHY。

PHY 复位也很关键。有些板子复位 GPIO 极性写反，上电后 PHY 一直处于复位状态。有些复位延时太短，PHY 还没准备好，MAC 就开始访问。还有些板子 PHY 供电由 GPIO 控制，Uboot 没打开这个电源，PHY 根本没工作。这类问题在自制板、核心板加底板、飞线调试时特别多。不要只看“网口灯亮不亮”，有些 PHY 在 link 没起来时灯就是不亮，而有些 PHY 默认常亮，不能作为唯一依据。

MDIO 读写是排查利器。不同 Uboot 命令不同，常见有mii、mdio。比如：

mdio list mdio read 0 0 mdio read 0 1 mdio read 0 2 mdio read 0 3

0x00是 BMCR，0x01是 BMSR，0x02和0x03是 PHY ID。如果读出来是0xffff，通常是 MDIO 通信失败、PHY 没供电、复位没释放、地址不对。如果 PHY ID 正常，再看 BMSR 的 link 状态位。链路没起来时，先查网线、对端网卡、自协商，不要直接改 IP。

2.3 千兆不通、百兆能通：延迟线、IO 电压和走线一起看

“百兆能 ping，千兆不行”是非常典型的 RGMII 问题。百兆时 RGMII 用 25MHz 时钟，千兆用 125MHz。频率一高，延迟、走线、IO 电压、参考时钟的问题就暴露出来。常见原因有：设备树没加内部延迟，PCB 走线长度不匹配，PHY 的 IO 电压和 MAC 不匹配，RGMII 的 TX/RX 延迟配置错误。你可以先强制百兆验证链路，再逐步定位千兆。Uboot 里有些 PHY 驱动支持mii命令写寄存器，但不要乱写，先确认 PHY 手册里的寄存器定义。

RK3568 这类平台在千兆模式下，rgmii-id往往是必须的。IMX6ULL 如果跑 RMII，本身只有百兆，不要拿千兆 PHY 的预期去套。FMQL 板子如果千兆不通，也要看 PHY 是不是支持 RGMII 延迟，或者 MAC 侧有没有延迟配置。还有一点，网线质量也会影响千兆。劣质网线百兆能通，千兆自协商直接降到百兆或者失败。换一根六类线，往往能排除很多“玄学”。

注意：不要看到“百兆能通”就认为硬件没问题。千兆对时钟和数据窗口更敏感，很多板子就是百兆正常、千兆丢包。先确认协商结果，再看延迟配置。

3. Uboot 配置、环境变量与驱动排查

3.1 环境变量最容易犯的错：IP、掩码、ethaddr、ethact

Uboot 环境变量里，和 ping 最相关的是ipaddr、serverip、netmask、gatewayip、ethaddr、ethact。ipaddr是板子自己的 IP，serverip是你要 ping 的目标 IP。很多人只改了ipaddr，忘记改serverip，结果 ping 的还是编译时的默认地址。还有人把netmask写成255.255.255.255，导致板子认为目标不在同一网段，ARP 请求发不出去。同网段 ping 时，gatewayip通常不参与，但设错也不会直接导致失败，除非协议栈实现比较特殊。

ethaddr也要注意。Uboot 里 MAC 地址如果全 0 或者全 F，有些交换机、虚拟网卡会直接丢弃。你可以在printenv ethaddr里确认，必要时setenv ethaddr 02:00:00:12:34:56。这个地址只要局域网内不冲突即可。多网口板子还要看ethact。比如 RK3568 有两个 GMAC，你插的是 GMAC1，但ethact是 GMAC0。Uboot 会拿 GMAC0 去 ping，而 GMAC0 可能没接 PHY 或者没插网线。切过去再试：

printenv ethact setenv ethact gmac1 ping 192.168.1.100

环境变量改完记得saveenv，否则重启就丢。但调试阶段别急着保存，先确认当前生效值。

3.2 DTS、pinctrl、时钟、CONFIG 检查清单

Uboot 设备树和 Linux 设备树可能不是同一份。很多人改的是 Linux DTS，Uboot 用的却是另一份 DTS，或者 Uboot 根本没使能对应节点。排查时先确认 Uboot 当前使用的 DTS，再看 MAC 节点状态是不是okay。检查pinctrl有没有配 RGMII 引脚，clocks和clock-names有没有使能，PHY 节点有没有被正确引用。RK3568 的 GMAC 节点里常见phy-handle、phy-mode、snps,reset-gpio，IMX6ULL 的 FEC 节点里常见phy-mode、phy-handle、fsl,magic-packet。

Uboot 配置也要看。CONFIG_CMD_NET、CONFIG_CMD_PING、CONFIG_CMD_MII、CONFIG_CMD_MDIO是否打开。对应 MAC 驱动有没有编译进去，比如CONFIG_ETH_DESIGNWARE、CONFIG_FEC_MXC、CONFIG_GMAC_ROCKCHIP。PHY 驱动有没有打开，比如CONFIG_PHY_REALTEK、CONFIG_PHY_MOTORCOMM、CONFIG_PHY_ATHEROS。如果 PHY 驱动没开，Uboot 可能只能读 ID，不能自动配置自协商。还有CONFIG_NET_RANDOM_ETHADDR这类选项，会影响 MAC 地址生成。

3.3 MDIO 寄存器与 ARP 观测：别只盯 IP

排查到中途，建议把 PHY 寄存器和 ARP 抓包结合起来看。PHY 侧先看 BMSR 的 link 位和自协商完成位。如果 link 没起来，后面都没意义。链路 up 后，看 Uboot 发 ping 时对端有没有收到 ARP。可以在 PC 或 Linux 虚拟机上抓包：

sudo tcpdump -i any -n -e arp or icmp

如果只看到板子的 ARP 请求，没有回复，说明广播包到了对端，但对端没回，或者回复没到板子。这时查对端 IP 是否同网段、防火墙是否拦 ARP、虚拟机是否桥接正确。如果连 ARP 请求都看不到，说明包根本没从对端网卡出来，问题在物理层、交换机、虚拟网卡或者板子 MAC。如果看到 ARP 回复，也看到 ICMP 请求，但没有 ICMP 回复，重点查防火墙。如果看到 ICMP 回复，但 Uboot 还说失败，那可能是 Uboot 驱动收包有问题，或者校验和、缓冲区配置有毛病。

Uboot 侧可以打开调试宏，比如CONFIG_NET_DEBUG、CONFIG_ETH_DEBUG，不同版本名字不一样。打开后能看到发送和接收计数。不要在生产版本里长期打开，调试完关掉。

3.4 回显含义分段判断：host is not alive 不等于全盘没救

Uboot ping 失败常见回显有几种。ping failed; host 192.168.1.100 is not alive是最常见的，表示发出了请求但没等到有效回复。ARP Retry count exceeded; starting again表示 ARP 阶段就失败了。No ethernet found表示 Uboot 根本没识别到网络设备。Could not initialize PHY表示 PHY 初始化失败。Link down或No link表示链路没起来。不同版本措辞有差异，但大致能分成三类：设备没起来、ARP 不通、ICMP 不通。

设备没起来，查驱动、DTS、PHY、时钟。ARP 不通，查同网段、交换机、虚拟网络模式、防火墙对 ARP 的处理。ICMP 不通，查防火墙、对端是否禁止 ping、虚拟化网络是否允许 ICMP。把回显和抓包结合，基本能定位到层。最怕的是只知道“不通”，不知道卡在哪一步。

4. PC 和虚拟机侧：防火墙、桥接模式和虚拟网卡

4.1 VMware、VirtualBox 网络模式怎么选：桥接最省事

虚拟机网络模式主要有桥接、NAT、仅主机。Uboot 要 ping 虚拟机，优先选桥接模式。桥接模式下，虚拟机像局域网里一台独立机器，和板子在同一广播域，ARP 能通，ICMP 也能通。NAT 模式下，虚拟机在主机后面，外部设备不能直接访问，Uboot 很难 ping 到。仅主机模式下，只有主机和虚拟机通信，板子如果不在这个虚拟网络里，也不通。

VMware 里可以在“虚拟网络编辑器”里看 VMnet0 桥接到了哪张物理网卡。如果你主机同时有 WiFi 和有线网卡，VMnet0 自动桥接可能选了 WiFi。板子插在有线网卡上，虚拟机却在 WiFi 网段，肯定不通。手动把桥接指定到板子实际连接的那张有线网卡。VirtualBox 里对应“桥接网卡”设置，也要选对物理网卡。WiFi 桥接有时对广播包支持不好，能用有线就用有线。

4.2 Windows 和 Linux 防火墙：ICMP 入站经常被默认拦

Windows 默认防火墙会拦 ICMP Echo Request。你在 PC 上能 ping 通别人，不代表别人能 ping 通你。Uboot ping PC 时，PC 必须允许入站 ICMPv4 Echo Request。可以在“高级安全 Windows Defender 防火墙”里新建入站规则，选择“自定义”，协议选 ICMPv4，类型选“回显请求”，允许连接。也可以临时关闭防火墙测试，但测试完记得恢复。域网络、专用网络、公用网络三个配置文件都要放行，尤其是虚拟机桥接后可能被识别为“公用网络”。

Linux 虚拟机也要看防火墙。Ubuntu 默认 ufw 可能是关闭的，但有些镜像会开。CentOS、Fedora 的 firewalld 默认可能拦 ICMP。可以临时放行：

sudo iptables -I INPUT -p icmp --icmp-type echo-request -j ACCEPT

firewalld 可以：

sudo firewall-cmd --permanent --add-rich-rule='rule protocol value="icmp" accept' sudo firewall-cmd --reload

还要确认内核没有全局忽略 ICMP：

cat /proc/sys/net/ipv4/icmp_echo_ignore_all

如果是 1，可以临时改为 0：

sudo sysctl -w net.ipv4.icmp_echo_ignore_all=0

注意：关闭防火墙只是定位手段，不是最终方案。定位完要按需放行 ICMP，不要把系统裸奔当成常态。

4.3 虚拟机没有网络适配器、VMnet1 感叹号、桥接失败怎么办

Windows 下 VMware 的虚拟网卡经常出问题。设备管理器里 VMnet1 有感叹号，通常是虚拟网卡驱动没装好，或者版本不匹配。可以尝试在 VMware 安装程序里修复安装，或者用管理员权限运行“虚拟网络编辑器”恢复默认设置。VMware 17 有时在 Windows 上会出现虚拟机没有配置和打开选项，或者网络适配器缺失。先确认 VMware 服务是否启动，比如 NAT 服务、DHCP 服务、桥接服务。VirtualBox 则要确认增强功能不是必需的，但桥接驱动要装好。

虚拟机里ip addr只有lo，说明网卡没被识别。先看虚拟机设置里网络适配器是否勾选“已连接”和“启动时连接”。有些虚拟机克隆后 MAC 地址冲突，也会导致网络异常。可以重新生成 MAC 地址。Linux 虚拟机里如果是 NetworkManager 管理，检查nmcli device status，看网卡是不是unmanaged。如果是unmanaged，可能是配置文件问题，需要把网卡交给 NetworkManager。

主机访问虚拟机网站、虚拟机 ping 不通网关，这些和 Uboot ping 虚拟机是不同层次的问题，但排障思路一样：先确认虚拟机能上网、能 ping 通主机、能 ping 通同网段其他设备，再让板子加入这个网络。不要一上来就让 Uboot 去 ping 一个自己网络都没配好的虚拟机。

4.4 用 tcpdump 和 Wireshark 确认包到底出没出去

抓包是解决“到底谁没回”的最快方法。在 Linux 虚拟机里：

sudo tcpdump -i any -n -e arp or icmp

在 Windows PC 上可以用 Wireshark，过滤器写arp || icmp。先看板子发出的 ARP 请求里，源 IP 是不是你设置的ipaddr，目标 IP 是不是虚拟机的 IP。如果源 IP 是 0.0.0.0，说明 Uboot 网络参数没生效。如果目标 IP 不对，说明serverip设错。如果 ARP 请求到了虚拟机，虚拟机也回了 ARP，但 Uboot 没收到，问题可能在虚拟机网卡、桥接、交换机。如果 ARP 正常，ICMP 请求也到了，但没回复，问题在防火墙或 ICMP 设置。

抓包时要注意接口。虚拟机可能有多个网卡，tcpdump -i any最省事。Windows 上选对虚拟网卡或物理网卡。如果只抓物理网卡，桥接的包可能看不到；如果只抓虚拟网卡，外部包可能看不到。先ipconfig或ip addr确认接口，再抓。

5. 实战排查流程：半小时定位 ping 不通

5.1 第一阶段：物理层与 PHY 链路检查

先把 Uboot 网络设备、PHY、链路状态确认一遍。启动板子，进 Uboot，执行bdinfo看有没有 eth 设备。用printenv看ipaddr、serverip、netmask、ethact。用mdio list看 PHY 是否被扫描到。读 PHY 的 BMSR，确认 link 和自协商。如果 PHY 都找不到，不要继续查 IP，直接查硬件、DTS、时钟、复位。如果 PHY 找到了但 link down，换网线、换对端网口、检查对端是否 up。如果 link up 但百兆/千兆不对，查 RGMII 延迟和接口模式。

这一阶段的目标是让 Uboot 知道“网线插着、PHY 活着、链路 up”。没有这个基础，后面所有操作都是白费。

5.2 第二阶段：ARP 与 ICMP 链路验证

链路 up 后，设置正确的 IP：

setenv ipaddr 192.168.1.10 setenv serverip 192.168.1.100 setenv netmask 255.255.255.0 setenv gatewayip 192.168.1.1 ping 192.168.1.100

同时在对端开抓包。如果看到 ARP 请求，没有 ARP 回复，检查对端 IP 是否同网段、是否允许 ARP、虚拟机是否桥接。如果看到 ARP 回复，没有 ICMP 请求，说明 Uboot 收到 ARP 后没发 ICMP，可能是驱动收包问题。如果看到 ICMP 请求，没有 ICMP 回复，检查防火墙和 ICMP 设置。如果看到 ICMP 回复，Uboot 仍然失败，可能是 Uboot 驱动收包异常，或者校验和、DMA 描述符问题。

5.3 第三阶段：交叉替换与对照实验

定位到可疑环节后，用替换法验证。换一根网线，换一个交换机，换一台 PC，换一张 USB 网卡。PC 能通、虚拟机不通，优先改虚拟机桥接模式。虚拟机桥接 WiFi 不通，换有线网卡桥接。Uboot 百兆能通、千兆不通，强制百兆或改 RGMII 延迟。A 板子能通、B 板子不通，对比设备树和 PHY 寄存器。不要同时改多个变量，一次只动一个，否则你不知道是哪个改动生效。

5.4 常见问题速查表

6. 几个容易忽略的坑与个人经验

6.1 Uboot 的 ping 不解析域名，别拿 www.baidu.com 去试

Uboot 里的ping通常只接受 IP 地址，不解析域名。你敲ping www.baidu.com，它要么报未知命令，要么把域名当非法参数。热词里有人遇到ping: www.baidu.com: Name or service not known，那是 Linux 的 DNS 问题，不是 Uboot 的问题。Uboot 阶段一般还没有 DNS 客户端，也不需要访问外网。调试板子时，用局域网 IP，别用域名。要传文件就用 TFTP 服务器 IP，要联调就用 PC 或虚拟机 IP。

6.2 自协商、双工、交叉线：老设备和新网卡会互相别扭

有些老 PHY 和新千兆网卡自协商会出问题。现象是链路 up，但丢包严重，或者只能百兆。可以尝试在 PC 侧强制百兆全双工，或者在 Uboot 侧通过 PHY 寄存器强制。交叉线现在大多数网卡支持自动翻转，但老交换机和老 PHY 不一定。如果你用的是直连板子和 PC，可以换交叉线试试。更省事的办法是中间加一个小交换机，让两边都按标准接法协商。很多“玄学不通”加个交换机就好了。

6.3 虚拟机桥接 WiFi 的兼容性，比你想的更差

用笔记本联调板子时，很多人只有 WiFi，没有有线网口。虚拟机桥接到 WiFi，有时能收到 ARP，但广播包会被过滤，或者桥接驱动对无线网卡支持不好。Uboot ping 虚拟机时，ARP 是广播，ICMP 是单播。广播在 WiFi 桥接下容易出问题。建议用 USB 千兆网卡，或者 USB 网卡加小交换机，把板子和虚拟机桥接到同一个有线广播域。这个方案很土，但成功率很高。VMware 里把 VMnet0 桥接到 USB 网卡，VirtualBox 里桥接名称选 USB 网卡，板子和虚拟机都设同网段 IP。

6.4 供电、复位和上电顺序，别等抓包才想起来

最后说一个最容易被忽略的坑：PHY 供电和复位时序。有些板子 PHY 和 MAC 共用电源，上电顺序不对，PHY 初始化失败。有些板子复位 GPIO 默认拉低，Uboot 没及时释放，PHY 一直复位。表现是 PHY ID 读不到，或者时好时坏。你可以用万用表量 PHY 电源，用示波器看复位脚。如果 Uboot 启动日志里 PHY 初始化偶尔成功偶尔失败，重点查电源和复位。还有时钟，25MHz 或 50MHz 参考时钟没起来，PHY 也不会工作。硬件问题用软件很难绕过去，早查早省事。

我个人在实际操作中的体会是，Uboot ping 不通时，先别急着改内核、改 IP、重装虚拟机。先按“PHY 链路、ARP、ICMP、对端防火墙、虚拟机网络模式”这条线走一遍，九成问题会自己浮出来。手上常备一根确认好的网线、一个百兆小交换机、一个 USB 有线网卡，能省下大量来回折腾的时间。