Repository navigation
FAQ
分平台看：
- **Windows：**会。只需安装一次，Guardian 会立即启动并随当前用户登录静默运行。为获得 WebSocket/流式代理的确定性保证，日常推荐从开始菜单打开 Codex (Managed Proxy)；继续点原图标也可以，证据不足时 Guardian 会先询问是否切换。
- **macOS：**会。只需安装一次，以后继续正常打开桌面应用。
- **Linux：**后台 Guardian 也会自动运行，但启动官方 Codex CLI 时请使用
codex-guard。后台进程无法改写另一个已经启动的终端环境。
如果当前 shell 本来就有正确代理，普通 codex 仍可能正常工作。但要确定使用 Guardian 刚刚验证过的代理，需要在新进程启动时注入环境，所以使用 codex-guard。它保留原终端和参数，也绝不会强杀或自动重启交互式会话。
项目目前没有商业代码签名证书，所以新的 EXE 可能触发 SmartScreen 信誉提示。这不应通过关闭安全功能解决：只从 CH-ZHOU-0512/codex-proxy-guardian 的正式 Release 下载并核对 .sha256；无法确认来源时使用可直接审阅的 ZIP 与 Install.ps1。
v1.4.0 起，Windows Setup EXE 显示确定的 0–100% 进度。解压部分按实际字节计算，其他部分按已完成的连通性、复制、自启、更新任务和 Guardian 健康验证阶段更新。某阶段需要等待时，百分比会暂停，旁边文字会说明正在等什么；这比伪造一个匀速增长的数字更准确。v1.4.1 还会确认 Guardian 进程真实存活；首次启动意外退出时进度显示安全重试，两次都失败则明确报错而不是显示假的 100%。
不是。它不提供代理服务器、订阅或节点，只负责让 Codex 跟随电脑上已经存在并通过验证的 HTTP/HTTPS、SOCKS5 代理或 PAC/WPAD 结果。
v1.3 起支持 SOCKS5/SOCKS5H，也会自动读取系统 PAC/WPAD，还可用 ExplicitPAC 手动指定 PAC URL。它不是只解析字符串：解析出的代理端点必须通过实际 HTTPS 请求验证后才会被采用。
当前不支持 SOCKS4、带账号密码的代理 URL，以及只有 TUN 而没有可见代理端点的环境。如果 PAC 为不同必需目标返回了互不兼容的路线，Guardian 会安全地不接管。
端口打开不代表它能代理真实 HTTPS 请求。Guardian 同时检查监听状态和经该代理发起的实际网络请求，达到成功门槛后才把候选视为有效。
v1.4.4 起，Windows 还要求 chatgpt.com 关键入口必须通过；API 与登录页成功不能再掩盖流式入口失败。
“正在重新连接”表示 Codex 的流式连接断开后正在重试，不等于 Guardian 重启了 Codex。请先对照同一时间的 Guardian 日志：存在 codex_restart 或 proxy_changed，才有 Guardian 生命周期动作的证据；若两者都没有，常见原因是当前代理服务商节点出现 TLS EOF、WebSocket reset、Windows 10054 或请求超时。
v1.4.5 起，Windows 设置页会直接显示这段边界说明，Status.ps1 与 Doctor.ps1 也会输出重连含义、应核对的事件和常见上游信号。Guardian 可以判断关键入口是否可用并尝试其他已发现候选，但它不是代理软件，不能在不改变用户网络选择的前提下修复服务商节点自身的丢包。遇到代理软件日志中的上游 i/o timeout，请手动换一个稳定节点。
v1.5.1 起还要看 StreamingProxyGuaranteed。若为 false 或 EffectivenessEvidence=SystemProxyHttpTrafficOnly，只能证明普通 HTTP 可能经过系统代理，不能证明 WebSocket/流式进程已继承显式代理；完成当前任务后同意一次修复提示，或关闭 Codex 后从 Codex (Managed Proxy) 打开。若已经是 ManagedTrafficObserved，且同期没有 codex_restart / proxy_changed，剩余重连更可能来自代理节点的上游重置或超时。
不会。它只读取系统代理与候选监听信息，并为 Codex 设置进程级代理环境或启动参数；不修改系统代理、WinHTTP、DNS、路由、防火墙或永久环境变量。
绝大多数用户保持默认自动（Safe）即可。Safe 会先观察真实流量；Windows 上普通启动产生的系统代理 HTTP 流量不再等于流式代理已生效，只有受管启动参数与新进程流量同时成立才保持不动。严格（Enforce）会更积极地要求启动参数一致，但同样受提示、防抖、冷却、频率限制和熔断保护。Linux CLI 无论哪种模式都不会被自动重启。
**Windows v1.4.3 起，Guardian 自己不会再静默关闭现有 Codex。**v1.5.3 使用简洁的品牌确认窗口，支持最小化和高 DPI 清晰显示。只有明确选择“重启Codex”才会执行；选择“60分钟后再提醒我”、关闭窗口、按 Esc、倒计时结束或界面失败都会保留当前任务。
自动发现时，同一个主机和端口的 HTTP/SOCKS 标记变化只记录诊断信息，不视为代理地址变化，也不会触发重启。如果 Codex 自身更新、Windows 或其他软件关闭了进程，则不属于 Guardian 能拦截的重启路径，可结合 Guardian 日志和系统事件继续排查。
更新会重启 Guardian 后台进程，不等于重启 Codex。v1.5.4 会在自动更新完成后通知一次，并明确 Codex 无需重启。Windows 如果随后确实需要校正 Codex，仍必须先得到前台的“重启Codex”确认；稍后提醒、关闭、超时或提示失败都会保留当前任务。macOS 仍受防抖、冷却、次数限制与熔断保护；Linux 更新不会结束或重启交互式 Codex CLI 会话。
通常不需要。Windows v1.5.0 起，Guardian 会识别 Codex 包版本变化，重新发现新路径和进程入口，进行兼容审计，并立即检查是否已有经过校验的 Guardian 正式版适配；没有新版时仍会每日检查。v1.5.1 起不使用 Codex 版本白名单：每个新包版本都会让旧证据失效，并重新验证关键目标、受管启动参数和新进程真实代理流量。
如果常规自动发现无法确认新版本兼容，Guardian 不会盲目反复关闭 Codex，而会显示 CodexCompatibilityReviewRequired 并暂停自动修复。完全未知的上游内部改动仍可能需要项目维护者发布一次适配；适配发布后，普通用户会通过自动更新拿到它，不需要自己重新开发或反复重装。
v1.5.2 起，Codex 更新触发的 Guardian 检查只有在任务返回终态后才会记录结果；失败会对同一个 Codex 版本自动重试，并优先使用 Guardian 已验证的代理。例外是仍在 v1.5.1、且只有经过该代理才能访问 GitHub 的机器：旧更新器可能下载不到修复自身的 v1.5.2，需要手动原位安装一次最新版。
Codex、ChatGPT 桌面应用、Windows、macOS 和 Linux 桌面环境都可能改变进程或代理行为。本项目是独立社区兼容方案，不是 OpenAI 官方代理守护 API。Guardian 已把变化发现、通用适配、重新验证、安全保持和适配更新自动化，但不能在未知接口出现前自动写出尚不存在的代码。它的承诺是：能确认时继续工作，不能确认时精确停止并保护任务，适配发布后再自动更新接管。
返回首页 · 本文档已与正式版 v1.5.4 同步。