在 VMware 里搭建 Ubuntu 与独立代理环境

先确定每一层的职责

这次实践从 Windows 宿主机开始。我使用 VMware Workstation Pro 创建 Ubuntu 客机，保留原有宿主网络，让客机通过宿主上的 Mihomo 入口访问选定的静态 ISP 代理。

最后形成的路径是：Ubuntu 应用先连接宿主的 VMnet8 专用代理入口，再由宿主代理转发到上游。VMware NAT 负责客机的基础联网，应用代理负责需要指定出口的请求，两层分别配置和检查。

我也保留了先前的 Windows 客机。切换到 Ubuntu 试验时，将另一台客机关机，减少同时运行带来的资源占用与排查变量。

实践中遇到的第一类问题来自 VMware NAT 与 DHCP。客机拿到地址、能连接宿主、能够访问外网，是需要依次确认的三个环节。

排查时先查看虚拟网卡、VMnet8 配置和相关服务，再检查客机当前地址与默认路由。基础联网恢复后，才继续测试代理。这样可以避免把 DHCP 或虚拟交换网络的问题误判成代理服务故障。

如果客机使用 DHCP，重新创建虚拟机或重启后要重新核对地址。宿主防火墙规则中限定的来源，也需要与实际客机对应。

宿主上的 Mihomo 为 VMnet8 提供独立监听，防火墙只允许指定客机连接对应端口。代理凭据放在本机配置里，文档使用占位符记录需要填写的字段。

部署时最容易混淆的是几种地址：客机自己的地址、宿主虚拟网卡地址、宿主代理监听、上游节点地址，以及外部网站看到的出口地址。先把它们画在同一条路径上，再逐项核对连接方向，会比反复修改整份配置更容易找到问题。

Ubuntu 安装完成后，我检查了时区、时间同步和软件源，并安装 VMware 的桌面集成工具。共享剪贴板、窗口交互和终端命令都分别确认，便于后续在宿主和客机之间整理资料。

命令行工具与图形桌面的代理设置也分别处理。先用显式代理请求确认目标入口可达，再查看图形应用是否读取了系统代理；APT 软件源、应用下载与模型客户端连接则按各自链路继续排查。

第一步检查客机能否连接宿主监听。第二步通过显式请求查看出口。第三步在浏览器里重复检查。最后，重新打开需要使用的桌面应用，发出一条新的实际请求，并对照宿主代理的连接记录。

这几步提供的是不同证据。外部查询返回出口地址，可以确认那一次请求的路径；应用安装成功，可以确认安装完成；应用获得回复，还需要结合来源、目标、路由与时间，才能进一步核对它使用的连接。

长连接可能在多次请求之间复用，因此排查时也要观察已有连接，不能只等一条新记录出现。遇到没有独立证据的部分，我会留在待验证清单中，后续再逐项补齐。

此次已经完成 Ubuntu 客机安装、虚拟网络恢复、宿主专用监听和防火墙配置，并记录了显式请求与浏览器的出口检查。桌面客户端的安装也有日志，但每个客户端、每种联网功能的完整代理路径仍需分别核对。

我把配置模板、服务检查顺序和恢复步骤整理在仓库中。后续更换客机地址、迁移电脑或调整代理时，可以从这些已确认的环节重新开始，而不必同时改变所有网络设置。