1. 问题背景
目标是在一台搭载 AMD 7840H 处理器、32GB 内存、运行 Windows 11 的笔记本上，搭建一套完全离线的 AI 翻译系统，实现印尼语 ↔ 中文的互译。选用 Ollama 作为模型运行框架，Pot Desktop 作为前端翻译工具，并下载了针对东南亚语言优化的 sailor2:8b 模型。系统曾正常工作约两天，之后突然出现 Pot 无法翻译的问题。
2. 环境说明
操作系统：Windows 11 专业版 (版本 26200)
CPU：AMD Ryzen 7 7840H
内存：32GB
软件栈：
Ollama (后台服务，监听 localhost:11434)
模型：sailor2:8b（后改为 hy-mt-local 测试）
Pot Desktop 3.0.7
网络环境：可能存在代理或 VPN（用户位于印尼），但最终问题与代理无关。
3. 故障现象
Pot 所有翻译功能失效，无论选择本地 Ollama 服务还是在线翻译服务（如百度翻译），均无响应。
Ollama 自身运行正常：通过 curl 测试 http://localhost:11434/api/generate 能正常返回流式响应。
重新安装 Pot、删除配置文件、更换网络环境、关闭防火墙均无效。
Pot 启动时日志显示无法检查更新（连接 dl.pot-app.com 失败），但翻译请求无任何日志输出。
4. 排查过程
4.1 确认 Ollama 服务正常
在命令提示符（CMD）中执行：
curl http://localhost:11434/api/generate -d "{\"model\":\"hy-mt-local\",\"prompt\":\"Hello\"}"
返回了一连串 JSON 格式的流式响应，表明 Ollama 服务完全正常，且模型已加载。
4.2 网络基础测试
nslookup registry.ollama.ai
能正确解析出 IP 地址（包括 IPv4 和 IPv6），说明 DNS 解析正常。
浏览器直接访问 http://localhost:11434 显示 “Ollama is running”，证明端口可达。
尝试其他翻译工具（如浏览器插件）调用本地 Ollama，成功工作，说明问题局限于 Pot。
4.3 Pot 日志分析
Pot 的日志（开启 RUST_LOG=debug 后）显示：
启动时尝试连接 dl.pot-app.com 和 github.com 失败，提示无法获取更新信息。
翻译操作没有任何网络请求相关的日志，甚至没有错误输出，说明 Pot 内部可能根本没有发起 HTTP 请求。
4.4 高级诊断工具
4.4.1 Process Monitor
用 Process Monitor 监控 pot.exe，过滤条件设置为 Process Name is pot.exe 且 Path contains 11434。在尝试翻译时，没有任何记录，证明 Pot 确实未尝试连接本地 Ollama 端口。
4.4.2 TCPView
使用 Sysinternals TCPView 实时监控网络连接，翻译操作时 pot.exe 没有任何新的网络连接出现，进一步确认 Pot 未发起任何网络请求。
4.4.3 事件查看器
在 Windows 事件查看器（eventvwr.msc）的 Windows 日志 → 应用程序 中，发现了 Pot 的崩溃记录：
事件名称: APPCRASH
P1: pot.exe
P2: 3.0.7.0
P3: 681eab80
P4: pot.exe
P5: 3.0.7.0
P6: 681eab80
P7: c000001d <-- 非法指令异常
P8: 00000000004c5589
这表明 Pot 在执行过程中发生了非法指令错误，导致程序崩溃，因此无法完成任何翻译请求。
4.5 尝试各种修复手段
卸载并重装 Pot（包括删除所有配置文件夹）
安装/修复 Visual C++ 运行库（遇到版本已存在错误，忽略）
关闭防火墙和杀毒软件
以兼容模式运行 Pot
使用 Pot 便携版（免安装）——同样崩溃
新建 Windows 用户账户测试——依然崩溃
所有常规手段均告失败，问题指向系统底层环境。
4.6 最终发现：Hyper-V 虚拟网卡冲突
几乎所有的原因都排查了，但是依然没有找到，问题既然出在pot上，并且确认是网络不通，笔者干脆从电脑的所有网络连接入手，发现除了hyper-v启用了虚拟网卡及网桥，没有其它可以怀疑的了，尝试关闭 Hyper-V 虚拟网卡后，Pot 立即恢复正常翻译。进一步确认：Hyper-V 的虚拟网络组件干扰了 Pot 对本地回环地址 (localhost) 的访问，导致 Pot 内部网络栈异常，进而引发非法指令崩溃。
5. 解决方案
5.1 临时解决方案
禁用 Hyper-V 虚拟网卡和网桥。
- 打开 网络和共享中心 → 更改适配器设置。
找到名为 “vEthernet” 或包含 “Hyper-V” 的虚拟网卡，右键 禁用。
或者直接关闭 Hyper-V 功能：
- 在 Windows 功能 中取消勾选 “Hyper-V”、“虚拟机平台” 等选项，重启电脑。
5.2 永久解决方案（若需保留 Hyper-V）
如果因为需要使用 WSL2、Docker 或其他虚拟机而必须保留 Hyper-V，可以采用以下方法避免冲突：
- 方法一：调整网络适配器优先级
打开 网络和共享中心 → 更改适配器设置。
按 Alt 键显示菜单，选择 高级 → 高级设置。
在 适配器和绑定 选项卡中，将物理网卡（如 Wi-Fi 或以太网）上移到第一位，将 Hyper-V 虚拟网卡下移。
重启 Pot 测试。
- 方法二：禁用 Hyper-V 虚拟网卡（不影响 Hyper-V 核心功能）
以管理员身份运行 PowerShell，执行：
Get-NetAdapter | Where-Object {$_.InterfaceDescription -like "*Hyper-V*"} | Disable-NetAdapter -Confirm:$false
需要时可用 Enable-NetAdapter 重新启用。
- 方法三：调整虚拟交换机配置
打开 Hyper-V 管理器 → 虚拟交换机管理器。
检查与物理网卡绑定的外部虚拟交换机，将其改为 内部 或 专用 模式，或取消与物理网卡的绑定。
6. 总结与建议
根本原因：Hyper-V 虚拟网卡干扰了部分 Windows 应用程序（尤其是基于 WebView2 的软件）对本地回环地址的访问，导致 Pot 崩溃。
教训：当应用程序突然无法访问 localhost 且常规网络排查无效时，应考虑虚拟化网络组件的干扰。
后续维护：若需同时使用 Hyper-V 和 Pot，采用上述优先级调整或选择性禁用虚拟网卡的方法，可以两者兼顾。
本次排障过程历时数天，综合运用了 curl、nslookup、Process Monitor、TCPView、事件查看器等多种工具，最终锁定 Hyper-V。希望这份记录能帮助遇到类似问题的用户快速定位问题。
- 附录：相关命令速查
# 测试 Ollama 是否正常
curl http://localhost:11434/api/generate -d "{\"model\":\"模型名\",\"prompt\":\"Hello\"}"
# 查看 DNS 解析
nslookup registry.ollama.ai
# 清除 WinHTTP 代理
netsh winhttp reset proxy
# 禁用 Hyper-V 虚拟网卡（PowerShell）
Get-NetAdapter | Where-Object {$_.InterfaceDescription -like "*Hyper-V*"} | Disable-NetAdapter -Confirm:$false
暂无评论