一台无人值守的 Windows 工作站可能需要全天运行构建、定时任务和远程访问服务，同时让实体屏幕保持黑暗。普通空闲计时器在本地使用时很直接，远程控制加入后就会产生冲突：远程键盘和指针事件可能点亮屏幕，全局空闲规则也可能在远程操作者仍在工作时再次黑屏。

一次脱敏工作站实践同时出现了这两类问题。手动黑屏可以生效，远程控制客户端的活动却会恢复可见桌面；全局空闲时长也无法判断当前究竟是桌面无人使用，还是存在活动远程会话。

最终方案采用远程会话感知的状态机。它把本地输入、远程连接事件、开机宽限期、断开宽限期和手动请求作为独立信号，并明确各自优先级。这里的“软黑屏”指把亮度降到最低，在所有显示器上覆盖纯 …

一个自动代理组看起来仍有多个延迟正常的节点，当前策略组却会突然显示失败并停止转发流量。直接选择界面中延迟最低的节点只能偶尔恢复，因为部分正延迟来自旧记录，代理核心维护的实时健康状态又是另一套数据。

最终处理方式是在现有客户端外增加一个很小的本地故障守护。它不改订阅，不替换代理核心，也不调整系统代理。真实请求正常时，守护保持观察；连续失败后才临时接管；自动组恢复稳定后，再把控制权交还给原有策略。

先区分展示记录与运行时健康状态

排查首先确认，界面同时呈现了两类含义不同的证据：

• 桌面客户端保存的单节点延迟记录；
• 代理核心维护的实时探测与选中状态。

第一类数据中的正数只能说明某次测量曾经成功，不 …

同一个网站在外部网络可以正常打开，在一台 Windows 工作站上却持续超时。浏览器、命令行和应用接口都受影响，但其他需要代理的网站仍然可用。

这种现象很容易被误判为网站宕机、证书异常或代理客户端整体失效。真正有效的排查顺序，是先把远端服务、本机解析和流量分流拆开验证。

现象与证据

外部探测确认首页和接口都能返回成功响应，证书链也有效。这说明服务端、域名证书和公开路由并没有整体故障。

本机的直接访问却连接到与外部解析不一致的地址并最终超时。与此同时，通过现有本地代理发送同样的请求可以成功。这组对照把问题范围缩小到了本机的解析与分流链路，而不是网站应用本身。

进一步检查代理客户端的活动规则后发现 …

我一直使用桌面快捷方式，在不开启 TUN 的情况下为 Codex 单独设置本地代理。一次应用和代理客户端升级后，双击快捷方式不再启动 Codex，也没有清楚的错误提示。

检查发现 Codex 安装本身正常，真正的问题是启动脚本和全局配置都写死了旧代理端口，而代理客户端已经切换到新端口。脚本在启动应用前检测失败并直接退出。

不再猜测端口

修复后的 PowerShell 脚本按以下优先级选择代理：

1. 用户显式传入的 Proxy 参数；
2. Windows 当前用户代理设置；
3. 没有有效代理时明确报错并停止。

系统代理可能是简单的 host:port，也可能按 HTTP、HTTPS 分项配置。脚本统一解 …