Roxi先分清“扩展停用”和“线路连不上”
SwitchyOmega 原仓库已注明不再维护。Chrome 官方时间表说明，Chrome 139 起不再运行 Manifest V2 扩展，2026 年 8 月 31 日商店移除了剩余 MV2 扩展。旧教程中“更新后重新启用就行”的方法，不能继续作为当前 Chrome 的通用步骤。原仓库仍保留历史安装说明，不表示其中每个入口今天都可用。
- 在 Chrome 菜单的“帮助 → 关于 Google Chrome”记下版本；打开 chrome://extensions，抄下扩展卡片上的实际状态。
- 如果提示不受支持，进入迁移流程；如果扩展仍能启用但网页失败，先核对它指向的代理客户端是否运行。
- 记录失败网址和错误原文。不要把不受支持、配置损坏和网络超时合并成同一种故障。
先保存规则，不急着卸载
选项页仍能打开时，用原扩展提供的备份入口保存配置，并记录每个情景模式的协议、主机、端口、PAC 地址与直连例外。打不开时，保留已有备份和扩展状态记录，手工重建必要规则。不要为取回规则去关闭浏览器安全更新，或安装来源不明的“复活版”。备份可能带有代理凭据和内网域名，只保存在自己控制的位置。
原项目明确声明，同名网站不当然属于项目维护者。迁移到其他扩展前，应从其项目说明核对商店入口、发布者、权限和支持范围；名字里包含 Omega 或外观相似，并不能证明出自原作者，也不能证明可直接导入旧格式。
选择一种主接管方式，避免配置互相覆盖
| 实际需要 | 可选择的迁移方向 | 验收重点 |
|---|---|---|
| 只有浏览器需要独立分流 | 支持当前浏览器的代理管理扩展 | 规则导入和端口协议分别验证 |
| 浏览器跟随已有客户端 | 停用旧扩展，使用客户端设置的系统代理 | 系统代理本身有效且客户端在运行 |
| 多个应用都需要接管 | 评估客户端支持的系统代理或 TUN | 逐个应用核验，不能由浏览器结果代替 |
Chrome 代理 API 中，system 是使用操作系统的代理配置，direct 是不通过代理。选择 system 不保证网络已经直连；操作系统里仍有代理脚本或手动端口时，它们仍可能生效。迁移前把这两种状态写清，避免关了扩展却继续连接一个已退出的客户端。
最小配置先通过，再逐条恢复规则
- 只启用本轮选定的代理管理方式。读取客户端实际显示的本地监听协议和端口，不把旧截图里的数字直接照搬。
- 同机监听地址通常使用客户端显示的回环地址；浏览器扩展的代理主机栏不是订阅导入框，不要把订阅网址填进去。
- 先用一条简单代理配置访问需要代理的普通测试页面，结合客户端连接记录确认请求进入预期路径。
- 再恢复一个直连例外，验证日常国内页面或局域网服务。最后逐项迁入其余规则，每次记录成功与失败。
如果页面仍失败，保留当前端口与错误，先回到已验证能用的系统代理方案做对照。只有扩展方式失败时，再查扩展规则或权限；两种方式都失败时，应继续查客户端和网络。切换配置后重新发起请求，别只观察一个尚未刷新的旧标签页。
退出与回退也要验收
关闭临时测试方式，恢复测试前记录的代理设置，确认普通网页、需要代理的网站和局域网访问各自符合预期。退出客户端前先关闭指向它的代理设置；需要保持代理的业务则留在已验证方案中。新方案重启后仍正常，再考虑清理旧扩展。迁移失败时恢复已保存的可用配置，提交版本、状态提示和脱敏规则，不提交订阅或密码。