这次复盘记录的是我们“Codex-Windows沙箱”项目的一次典型网络故障从出现症状到定位根因花了六个多小时。如果你也在用Windows Sandbox跑自动化服务那这个真实案例的排查脉络和坑点应该能帮你省下不少时间。故障本身并不复杂但极具迷惑性Windows沙箱能正常启动网络也通可沙箱里的Codex服务就是起不来一直卡在“连接内部模型网关”那一步。我们反复重启、改配置、看日志最后才找到真正的问题出在宿主机安全软件更新后对Hyper-V虚拟交换机的“过度保护”上。这个案例的每一步排查思路和每一行命令我都整理在下面了。1. 故障背景与环境搭建1.1 为什么用Windows沙箱跑Codex先说背景。我们在维护一个代号为“Codex”的代码生成服务它需要在一个隔离的Windows环境里执行一次性任务。这个服务会读取临时脚本、调用内部模型网关、编译并运行用户提交的代码片段安全要求比较高不允许直接跑在宿主机上。当时可选方案有三个传统虚拟机Hyper-V隔离性最好但启动要几十秒甚至几分钟每次还要维护快照、处理系统更新运维成本高。Docker容器启动快、资源省但我们的Windows容器镜像里缺一些底层API而且容器共享宿主内核对“代码生成后还要调用Windows系统接口”这种场景不够干净。Windows Sandbox微软自带的一次性轻量虚拟机秒级启动无状态关掉即销毁天然适合“跑一次、扔一次”的临时任务。我们最终选了Windows Sandbox。主要看重它三点启动快、全隔离、没有License成本。Windows Sandbox基于Hyper-V底层能力但比传统VM更轻因为它使用一组动态差异磁盘每次启动都是全新系统。下面是我们当时的环境配置项目配置宿主机Windows 11 Pro 22H28核16线程32GB内存SSD剩余150GB沙箱规格CPU 2核内存4GB启用网络映射只读目录Codex服务沙箱内的.NET服务监听5000端口启动时从模型网关拉取模型清单模型网关地址model-gw.local通过内部DNS解析调度器宿主机上的Windows计划任务调用沙箱执行任务共享目录宿主机D:\codex_share映射到沙箱C:\share沙箱的启动配置由一个.wsb文件控制核心内容是这样的Configuration MappedFolders MappedFolder HostFolderD:\codex_share/HostFolder SandboxFolderC:\share/SandboxFolder /MappedFolder /MappedFolders LogonCommand CommandFileC:\share\bootstrap.cmd/CommandFile /LogonCommand MemoryInMB4096/MemoryInMB VirtualProcessorCount2/VirtualProcessorCount Networkingtrue/Networking /Configurationbootstrap.cmd会调用一个PowerShell脚本等待网络就绪然后启动Codex服务。这个架构看起来没什么问题但我们忽略了一个关键细节沙箱内的DNS解析完全依赖宿主机的转发机制。一旦宿主机侧对沙箱的DNS请求做手脚整个服务就瘫了。这次故障恰恰就出在这。1.2 Codex服务为什么必须访问模型网关Codex服务并不是一个纯本地程序。它启动时要做三件事加载本地模型配置。连接内部模型网关model-gw.local获取最新的模型版本、许可证校验、算法参数。服务就绪后监听TCP 5000端口等待宿主机调度器下发任务。如果第2步失败服务不会立即退出而是会重试几次每次间隔5秒最终抛出一个“上游连接失败”的异常。这个重试设计本意是好的结果在故障发生时反而掩盖了根因让我们一度以为是服务代码或网络延迟的问题。现在想想如果Codex服务在启动时能把“依赖DNS解析”变成“依赖IP直连”这次故障可能压根不会影响业务。但当时没有这种意识后面会详细讲。2. 故障现象与第一现场2.1 故障具体表现10月8日早上9点15分左右调度器反馈连续三次任务都失败了错误信息都是“Codex握手超时”。我马上手动启动了一个沙箱进去以后发现Codex服务进程还活着但5000端口没有监听。查看服务日志发现它卡在同一个地方[09:21:03] INFO Connecting to model gateway: https://model-gw.local/api/v1/models [09:21:08] WARN Connection attempt 1 timed out [09:21:13] WARN Connection attempt 2 timed out [09:21:18] WARN Connection attempt 3 timed out [09:21:23] ERROR Failed to initialize model gateway, shutting down.这个日志看起来像是网关不可达但我马上在沙箱里做了一个简单测试ping model-gw.local结果直接显示找不到主机。然后我又用IP地址ping了一下模型网关的内网IPping 10.3.0.45结果立刻通了。也就是说沙箱的网络链路是好的TCP/IP能走通问题纯粹出在DNS解析上。为了验证我执行了nslookup model-gw.local等待了大约10秒返回的是DNS request timed out. timeout was 2 seconds.当时心里基本有数了这不是Codex的问题也不是网络断了而是沙箱里的域名解析不可用。2.2 初步判断与影响范围一开始我们猜测是不是沙箱的网络配置漂移了于是尝试重启沙箱而且重启了两次。第二次重启时我特意在沙箱桌面加载完成后立刻执行nslookup model-gw.local。有趣的现象来了第一次解析成功了但紧接着再执行一次又超时了。这个细节很关键。它说明沙箱从宿主机继承的初始DNS配置是生效的但生效状态只能维持几秒钟之后就莫名失效。我当时怀疑是宿主机上某个服务在动态修改网络策略于是把排查重点转向了宿主机的网络转发环节。影响范围方面因为Codex服务启动失败当天上午所有依赖代码生成的任务都无法执行。调度器上没有做“自动重试N次”的策略只有一次性触发所以任务队列全部阻塞。最直接的损失是项目进度延误但也让我们有机会彻底检查一遍这套沙箱架构的稳定性。3. 排查过程实录3.1 第一轮瞎忙活与表面检查我们最开始做的是一些常规检查现在回想起来基本属于“瞎忙活”。先看了Hyper-V相关服务是否正常Get-Service vmcompute, hvhost, vmms三者的状态都是Running。再看Windows Sandbox的进程Get-Process WindowsSandbox -ErrorAction SilentlyContinue进程也在。接着去事件查看器翻日志Microsoft-Windows-Hyper-V-VmSwitch-OperationalMicrosoft-Windows-WindowsSandbox/Operational日志里只有一些常规信息没有任何红色错误。于是我们想通过“重新安装Windows Sandbox功能”来修复但这个操作必须重启系统而且影响面大没有立刻执行。这半小时属于典型的“症状驱动排查”——看到什么查什么没有抓住“IP能通但DNS不通”这个明确的矛盾点。真正高效的排查应该是先区分“服务没起来”还是“服务起来但依赖问题”然后逐层下沉到网络协议栈。3.2 第二轮从网络层开刀第二轮我开始认真看沙箱内的网络配置。在沙箱里执行ipconfig /all关键信息如下沙箱IP172.25.192.5网关172.25.192.1DNS服务器172.25.192.1这个172.25.192.1是宿主机的“vEthernet (Default Switch)”接口。Windows Sandbox默认使用Hyper-V的Default Switch所以沙箱的网关和DNS都是同一个地址。在沙箱里ping网关ping 172.25.192.1通。这说明沙箱到宿主机NAT网关之间没有问题。但为什么DNS请求没响应用Resolve-DnsName再测试一次Resolve-DnsName -Name model-gw.local -Type A结果没有任何返回最后抛出了超时错误。这里也踩了一个小坑很多人会用Test-NetConnection model-gw.local -Port 53来测DNS但 TCP/53 根本不是默认DNS服务。DNS查询走的是UDP/53而Test-NetConnection默认只支持TCP所以它给出的结果没有参考价值。正确测法是直接Resolve-DnsName或者用nslookup。3.3 第三轮抓包定位DNS既然沙箱内的测试已经表明“有IP、有网关、但DNS无响应”那问题要么出在沙箱的DNS客户端要么出在宿主机侧的转发环节。为了区分这两者我在沙箱内用系统自带的抓包工具开了一个追踪会话netsh trace start captureyes scenariodns然后执行nslookup model-gw.local触发一次DNS查询。抓包完成后把生成的ETL文件拷出来分析。结果很明确沙箱已经发出了DNS查询请求源地址是172.25.192.5:54321目的地址是172.25.192.1:53但这个请求发出去之后再也没有任何回应包。DNS请求反复重传了几次最终超时。这说明沙箱的DNS客户端没有问题问题出在宿主机“收到这个请求并转发到真实DNS服务器”这个环节。接着我在宿主机上也开启一个网络监听过滤UDP 53端口的流量结果发现来自172.25.192.5的DNS请求根本没有出现在宿主机的物理网卡上。也就是说请求在Default Switch内部就被丢弃了。到这一步我基本确定是宿主机防火墙或第三方安全软件拦截了虚拟交换机上的DNS转发流量。3.4 转折点防火墙规则与系统补丁为了验证这个判断我尝试暂时退出宿主机上的第三方安全软件然后再回到沙箱里执行一次Resolve-DnsName model-gw.local结果立刻成功。然后我重新启动安全软件再测一次又超时了。反复验证了两次结论完全一致。打开安全软件的管理界面发现它把“vEthernet (Default Switch)”这个网络接口标记成了“不信任网络”并且自动启用了一条“DNS过滤规则”。这条规则的生效时间正好是10月8日凌晨也就是安全软件自动更新完之后。为什么普通Hyper-V虚拟机不受影响而Windows Sandbox会被拦因为Sandbox使用的Default Switch是系统自动创建的特殊虚拟交换机安全软件对它进行了单独的网络分类一旦它被归入“不信任网络”默认就会丢弃所有DNS查询以此作为一种防护策略。这个行为设计上是为了防止恶意虚拟网络间解析防止DNS劫持但在我们的内网环境里反而成了误伤。4. 根因分析与修复步骤4.1 根因最终解释一句话总结沙箱的DNS请求通过Default Switch转发到宿主机时宿主机上的安全软件更新后把Default Switch网卡划为“不信任网络”并启用了DNS过滤策略导致沙箱发出的UDP 53请求被静默丢弃。为什么是“静默丢弃”而不是“拒绝”安全软件对“不信任网络”的默认策略通常是DROP而不是REJECT。DROP会让请求方一直等待到超时表现成“间歇性网络故障”。如果当时是REJECT沙箱会立刻收到“网络不可达”的ICMP消息反而更容易定位。另一个诱因是Codex服务的设计模型网关地址使用域名model-gw.local并且没有做IP直连或hosts兜底。一旦DNS失效服务就必死无疑。如果当初服务配置里直接用https://10.3.0.45/api/v1/models那么这次故障根本不会影响业务。这也给我们敲了个警钟高可用不是只靠重试就能实现的关键依赖要尽量减少单点。4.2 临时快速恢复方案确认根因之后我们立刻采用一个无侵入的临时方案在沙箱启动脚本里强制将DNS配置为内部DNS服务器绕开宿主机的Default Switch转发。在沙箱内执行以下命令即可Get-NetAdapter -Name Ethernet | Set-DnsClientServerAddress -ServerAddresses (10.3.0.100, 10.3.0.101)这里的10.3.0.100/101是我们内部网段的权威DNS服务器。沙箱访问这两个地址的路径是沙箱 → Default Switch NAT → 宿主机物理网卡 → 内部DNS服务器安全软件虽然拦截了 Default Switch 的DNS转发代理但不影响沙箱经过NAT后直接访问业务段的DNS服务。所以这个方案能立刻生效。但要注意Windows Sandbox每次启动都是全新环境必须把这一步写进启动脚本不能只在当前打开的沙箱里手动执行。修改后的bootstrap.cmd内容如下echo off powershell.exe -ExecutionPolicy Bypass -File C:\share\bootstrap.ps1bootstrap.ps1开头改成这样$dnsServers (10.3.0.100, 10.3.0.101) $adapter Get-NetAdapter -Name Ethernet Set-DnsClientServerAddress -InterfaceIndex $adapter.ifIndex -ServerAddresses $dnsServers # 等待网络就绪 Start-Sleep -Seconds 2 # 验证DNS $resolved Resolve-DnsName model-gw.local -ErrorAction SilentlyContinue if (-not $resolved) { Add-Content -Path C:\Windows\System32\drivers\etc\hosts -Value 10.3.0.45 model-gw.local } # 启动Codex服务 Start-Process -FilePath C:\share\codex-service.exe -ArgumentList --config, C:\share\config.json这里用了一个if (-not $resolved)的逻辑兜底如果DNS手动配置后仍然解析不了就直接写hosts保证Codex服务能启动。Write-Host这些调试输出可以根据需要加上。4.3 永久加固三层方案临时方案虽然能恢复业务但我并不想长期依赖它。所以后续做了三层永久加固第一层调整安全软件策略。在安全软件中把“vEthernet (Default Switch)”这个虚拟接口重新标记为“信任网络”并且放行DNS转发流量。这个操作需要与安全运维人员确认不能自己乱改因为涉及到整体安全基线。第二层沙箱启动脚本标准化。把“自定义DNS hostst兜底 网络自检”做成标准模板以后凡是跑Windows Sandbox的调度任务都自动加入这个启动逻辑。这样即使宿主机的安全策略再发生变化沙箱内部仍然具备自愈能力。第三层应用配置改造。把Codex服务的主机配置从域名改成IP直连域名只保留在日志里做展示用途。以后即使DNS彻底挂了服务也能启动。这一步是治本但涉及代码改动和发布流程所以安排在下个版本上线。最终.wsb文件也做了小调整比如把映射目录设为只读避免沙箱内意外写入损坏宿主机文件Configuration MappedFolders MappedFolder HostFolderD:\codex_share/HostFolder SandboxFolderC:\share/SandboxFolder ReadOnlytrue/ReadOnly /MappedFolder /MappedFolders LogonCommand CommandFileC:\share\bootstrap.cmd/CommandFile /LogonCommand MemoryInMB4096/MemoryInMB VirtualProcessorCount2/VirtualProcessorCount Networkingtrue/Networking /Configuration4.4 验证与监控修复后我们连续跑了三个真实任务全部成功。后面又专门做了一个DNS断网演练在沙箱启动时手动把安全软件的DNS过滤打开确认启动脚本能够自动切换到hosts兜底Codex服务依然正常启动。同时给调度器加了一个健康检查沙箱启动30秒后如果Codex服务的5000端口没有监听就自动标记失败并轮询重启。这避免以后再次出现“沙箱进程在跑但服务起不来”时任务队列静默卡住的情况。监控项我整理成了表监控点检查方式告警条件DNS解析Resolve-DnsName连续3次超时服务监听Test-NetConnection -Port 500015秒内未监听沙箱进程Get-Process WindowsSandbox进程退出安全软件规则读取安全软件日志防御规则变更时产生通知5. 常见问题排查速查表这次故障之后我趁热整理了一份Windows Sandbox网络问题速查表之后排查类似问题可以直接对照。现象可能原因排查方向沙箱内DNS解析超时但IP可ping通宿主机DNS转发被拦截检查Default Switch网卡的防火墙/安全软件策略沙箱无法访问外网但宿主机正常宿主机防火墙拦截虚拟交换机出站流量临时关闭Windows防火墙测试确认规则沙箱启动后黑屏或卡登录Hyper-V服务异常或内存不足查看Hyper-V事件日志检查可用内存共享文件夹不可见.wsb映射路径错误或UNC路径不支持使用本地绝对路径避免带空格沙箱启动失败报错0x80070005权限不足或防病毒拦截以管理员运行检查安全软件隔离区另外有两个容易被忽略的坑单独说一下第一个坑沙箱内DNS一开始正常过一会儿才超时。这通常是宿主机安全策略或DNS转发进程在沙箱运行后才开始生效不是沙箱配置问题。别浪费时间反复重启沙箱直接看宿主机侧的规则变更。第二个坑Test-NetConnection测不了DNS。我见过有人用Test-NetConnection 10.0.0.1 -Port 53去测DNS这是不对的。TCP/53不是标准DNS端口测出来的结果没意义。测DNS就用Resolve-DnsName -Name model-gw.local -Type A -DnsOnly-DnsOnly参数可以忽略hosts文件只走实打实的DNS协议排查更干净。6. 经验总结这次故障真正的问题不在Codex也不在Windows沙箱而是“网络依赖链路里被忽略的一环”。我们一直默认沙箱的DNS是可用的结果一个安全软件更新就能让整个系统停下来。复盘完之后我最大的改变有两个。第一个改变是凡是关键服务之间的调用尽量用IP地址或本地hosts兜底不要依赖“动态DNS”这种外部变量。尤其在这种一次性的沙箱环境里系统生成得快网络策略却不受你控制能用静态解析决不用动态解析。第二个改变是对于Windows Sandbox这类动态环境启动脚本里必须先做“自检 兜底”。网络通了再启动服务不通就自动走到hosts逻辑让异常在沙箱内部消化掉而不是反馈到上层调度器。如果你也在维护类似的Windows沙箱任务我建议你回头看看自己的启动脚本里有没有这三行等待网络就绪、测试DNS、写入hosts兜底。没有这三行哪怕今天不出事明天也可能栽在某个安全软件更新上。