Chrome 扩展：回读生效的代理配置
在把 set 回调当作浏览器实际路由的证据之前，先检查完成状态、value.mode、levelOfControl 和范围。
settings.set() 成功完成所能说明的，远少于通过预期端点成功发起的一次浏览器请求。在异步操作完成后回读生效的 ChromeSetting，并首先处理其错误路径。
| 回读细节 | 它回答的问题 |
|---|---|
value.mode | 这是系统配置、固定服务器还是 PAC？应读取与该形态相符的字段，而不是假定存在顶层主机。 |
levelOfControl | 此扩展能否控制该设置，它是由此扩展还是其他扩展控制？受管理的策略可能限制更改。 |
| 范围与浏览上下文 | 你检查的是常规配置还是预期的无痕模式配置？请使用 API 文档中的读/写选项。 |
在 set 操作开始后立即发起的读取可能与其竞争。读取错误的属性可能使有效的系统或 PAC 配置看起来为空。这两种观察都不能证明远程代理拒绝了任何东西。
如果某项设置控制被禁用，应检查控制它的策略或扩展，而不是反复写入与之竞争的另一处存储。Chrome 可以组合系统设置、命令行配置、扩展和策略。
理解生效配置后，检查通往目标的路径。PAC 或绕过规则可能有意选择直接访问。如果它选择了预期代理，端点可用性、身份验证以及 观测到的出口仍然是实际浏览器请求要回答的问题；配置回读不是健康检查。