用途与实际影响
这项功能怎样使用
为什么需要它
不同程序可能用不同代理路径。若把订阅获取失败当成全部网页流量失败，或让依赖当前网络的远程 AI 只看自己幸存的连接，就容易修错地方。
举个实际例子
“我不知道为何上不了网。”先双击唯一入口；若发现失效设置，界面给出中文预览，确认后保存原值、修复并分别报告配置与微软网页结果。若未发现可修复设置，仍给出下一步。若是订阅更新失败而现有节点可用，则另按历史方法分开检验订阅和网页流量。
最后我会得到什么
先得到本机检查与下一步入口；执行后分别看到客户端是否退出、设置是否改变、基础网页是否可访问，以及没有覆盖的应用。历史端口与热点经验保留原日期，不当作今天的检测结果。
正常时
唯一双击入口能打开首页；只读检查后，选择的修复或关闭动作都有预览、确认和回读。
发现问题时
远程 AI 可能看不到真正断线的那一刻；此时以本人现场描述和本机独立检查为准。
入口不可用或证据不足时
需要账号、订阅凭据或客户端私有配置时，网页不能代读；在本人本地客户端处理。
从哪里开始
日常从“00-打开 ProxyClean.vbs”进入；高级诊断点“查看详情”，网络专项动作点“维护工具”。
需要准备什么
- 具体断网或订阅症状
- 是否还需要代理
- 是否同意额外网页或公网出口测试
从开始到拿到结果
- 1
先区分故障
首页给出本机代理与简短结论；订阅、热点、浏览器和应用连通性是不同问题。
- 2
选相应窗口
普通修复先预览；高级窗口才处理 DNS、网卡、IPv6 和可选出口比较。
- 3
确认结果与撤销边界
技术诊断仅主动复制脱敏版本；Undo 只撤回仍与本轮结果一致的配置，不能复活已关闭进程。
技术实现与依据
这里保留实现、关键条件、精确入口、历史记录和验证结果。
双操作图形首页已发布，旧快捷方式归入旧版入口；历史测量不冒充当前网络状态关键规则与设计选择
打开窗口不要求预先提权；只有所选受保护动作需要时才请求 UAC，并保留选择、重查现场、再次确认。旧快捷方式保留在旧版入口。
日常预防姿态是只保留一个主要代理路径：客户端 TUN/虚拟网卡负责出站，终端和项目不固定 HTTP_PROXY/HTTPS_PROXY/ALL_PROXY 或第三方 API 端点；System Proxy 默认关闭。
DNS 覆写默认关闭；只有另行证明 Codex/Claude App 连通性不受影响时才逐项试验，不为浏览器泄露分数牺牲 App 路径。
控制面负责取得订阅/节点列表，数据面负责实际代理流量；一个失败不能自动证明另一个失败。
历史 :5413 RST 来源在本地残留、光猫或机场策略之间保持 Unknown（未验证）；:443 链接与手机热点是当时验证过的绕行/恢复，不是所有故障通用答案。
浏览器 DNS/WebRTC（网页实时通信）/时区信号只说明浏览器环境，不等于 Codex App、Claude Code 或终端拥有同样路径。
fallback（后备路线） 只剩 DIRECT-only（仅直连）参考、历史手工启动和历史状态入口；没有安装、自启或现役上游。
本模块用到的名词
- Control Plane（控制面）
- 负责登录、取订阅和更新节点列表的路径；它可以失败而已有代理节点的数据流仍可用。
- Data Plane（数据面）
- 实际承载浏览器、终端或 App 流量的代理路径；需要用真实请求判断，不能只看客户端测速颜色。
- Observation Blind Spot（观测盲区）
- 远程 AI 依赖代理在线才能对话，因此采到的状态天然偏向“已经能连”的幸存样本。
- WebRTC（网页实时通信）
- 浏览器可暴露候选网络地址的一类网页能力；它的结果不能直接外推到本地 App 或终端。
专业定义
保留历史更正和 Unknown（未验证），不把一次旧故障、UI（界面）测速或远程幸存者样本套到当前现场
解决什么
避免把订阅控制面故障、节点数据面、DNS/TUN、浏览器 WebRTC（网页实时通信）/时区信号和 Codex/Claude App（应用）连通性揉成一个“代理坏了”。
当前怎样实现
- 根目录唯一 VBS 检查完整文件包并启动 ControlCenter.ps1；首页只做本机只读检查，异常启动有中文提示。旧批处理及重复 VBS 移到旧版入口并修正相对路径。
- 主清理发现 WinINET 活端口与活动 fake-ip TUN 同时存在时只输出多路径告警，不替用户选择或关闭客户端。
- 2026-06-28 故障文档保存同一订阅在不同出口的 HTTP（网页传输协议）状态/字节证据、:5413 与 :443 分层、手机热点恢复和观测盲区。
- Claude Code / Codex App 文档把 TUN/App 连通性和浏览器 DNS/WebRTC（网页实时通信）/时区测试分开，明确不要用终端代理变量修浏览器信号。
- fallback（后备路线）/config.yaml 为 DIRECT-only（仅直连）参考，start-hidden.vbs 与代理状态.bat 仅作历史材料，没有任务或启动项调用。
- ControlCenter.ps1 和共享 Workflow/Clients 模块提供双意图首页、后台检查、修复/关闭确认、设置回读与基础网页核验；Details.xaml 与 Maintenance.xaml 分别承接折叠日志和技术操作，无常驻修复服务。
执行流程
- 1
双击 00-打开 ProxyClean.vbs，先看本机代理结论；若 WinINET 与 TUN 同时活跃，界面只说明多路径。需要时选检查修复或关闭代理，后者按客户端动态归组，技术操作进入独立维护窗口。
- 2
把失败拆为控制面、数据面、DNS/路由、浏览器环境和具体 App 路径。
- 3
使用对应证据验证一层，不用 UI 测速、单个 200 或 AI 在线状态证明全链。
- 4
保留后续更正和 Unknown（未验证），交回当前可用恢复点及下一次应由用户现场验证的步骤。
边界
- 历史案例是方法和已脱敏证据，不是当前账号、节点、家庭网络或端口状态。
- 日常不把代理端口写进终端环境、项目配置或 shell profile（终端启动配置），也不把第三方 API 地址冒充官方端点。
- 网页不公开订阅 token、账号密码、完整公网 IP、客户端私密配置或节点明细。
- 首页关闭客户端先尝试正常退出，未完成才另行确认强制关闭；旧按端口快捷方式是维护兼容入口，不能替代当前客户端归组判断。网站刷新和启动只读检查都不执行关闭。
- 浏览器侧治理只应作用于浏览器，不为追求泄露测试结果破坏已验证的 App/TUN 连通性。
失败与恢复
- 客户端 UI 显示所有节点 Timeout（等待超时）
- 先用小请求/真实数据面测试，不把批量测速误报直接当成节点全坏。
- WinINET 活端口与活动 fake-ip TUN 同时存在
- 主清理只告警多路径，不自动停任何客户端；用户先明确哪条是主路径，再用客户端界面或显式关停入口处理。
- 订阅更新失败但已有节点仍能上网
- 分开测试订阅控制面与数据面；保留 :5413 RST 来源 Unknown（未验证），并使用已验证的 :443 或热点恢复思路。
- AI 在线时看见所有探测都正常
- 标注幸存者偏差，不能用在线样本证伪用户真正断线时的观察。
- DNS/WebRTC 检测与 Codex/Claude App 结果不一致
- 分别处理浏览器和 App 路径，不用一个表面的泄露分数牺牲工作连接。
真实入口
00-打开 ProxyClean.vbs / ControlCenter.ps1 / ControlCenter.xaml唯一日常双击入口及双意图图形首页
ProxyClean.Workflow.ps1 / ProxyClean.Clients.ps1 / Details.xaml / Maintenance.xaml共享修复与客户端关闭流程，以及独立详情、维护窗口
旧版入口/旧批处理和重复 VBS 的兼容位置；不是当前日常入口
docs/2026-06-28-wifi-subscription-403-troubleshooting.md订阅控制面、数据面、:5413/:443、热点恢复与观测盲区证据
docs/claude-code-tun-browser-leaks.mdTUN/App 连通性与浏览器 DNS/WebRTC/时区边界
fallback/config.yaml / fallback/start-hidden.vbs / fallback/代理状态.batDIRECT-only 与无自启的退役参考
如何验证
- 2026-09-24 源 CHANGELOG 记录新增 12 项注册表隔离回归、整仓 193 项双 PowerShell 通过；9 月 22 日 WPF 只读烟测、六条导航与隔离客户端关停仍是原日期证据。本站未复跑真实网络效果。
- 公开文档保留同一历史排查中前后推翻的结论、HTTP 状态/字节证据与明确 Unknown（未验证）；网页按最终更正而不是早期猜测解释。
- 本轮没有复现 2026-06-28 的订阅、热点、光猫、浏览器泄露或真实 App 故障，不能把历史数据升级成当前 E2E（端到端验证）。
与其他模块的关系
负责唯一日常启动、两种用户意图与详情/维护分层，同时保留两类长期故障诊断方法。