自动代理脚本不是订阅：沿着PAC的返回结果找入口

系统代理设置中的“自动”容易让人以为不需要再检查任何东西。实际上，PAC脚本负责告诉支持它的应用怎样连接某个目标，它本身既不是机场账户，也不替你启动代理程序。自动选择、脚本取得和代理可用，应分别验证。

PAC在应用请求前作出选择

常见PAC脚本通过FindProxyForURL接收URL与主机信息，按逻辑返回代理或直连等结果。它表达的是某次请求应交给谁，不是完整的节点订阅。将PAC地址导入普通节点配置区域，通常不符合这两种内容的职责；应使用应用或系统明确支持的自动代理入口。

手动代理直接填写服务器和端口；自动配置脚本指定一份用于决策的脚本；自动检测则涉及寻找适用配置的机制。具体支持与优先级由系统和应用决定，不能因为三个选项都在同一页就认为它们等价。操作前记录原状态，尤其在工作设备上不要覆盖组织安排。

假设PAC把某类网站交给本机端口，这个端口仍需有相应程序监听，客户端也需要有效配置。脚本能被浏览器取得，只完成了一步。若程序已经退出，应用可能继续按脚本请求旧入口，从而出现网页无法加载。先核对返回目标和监听状态，比反复重新保存PAC地址更有意义。

某个浏览器使用系统PAC，命令行工具或另一应用可能采用独立代理，也可能不支持相同机制。因此同一网址在不同工具中的结果，需要先比较它们读取的设置。不要把浏览器成功当作整台电脑都经过脚本，也不要用一个工具的失败推断脚本对所有应用失效。

选择一个按设计应代理的普通目标和一个应直连的目标，分别观察实际请求与客户端记录。保持网络、账户和客户端不变，避免同时改脚本与节点。若脚本涉及本地地址或域名条件，应查对应逻辑而不是凭页面标题猜测。不要将带私人凭据的配置交给不明在线编辑工具。

PAC能够影响应用连接去向，应只使用可信来源和清楚用途的配置。临时使用完成后，恢复原有自动代理设置，并确认客户端关闭后基础网络正常。保存必要用途说明，不公开包含敏感地址的脚本。最终应能解释脚本从哪里取得、对哪些应用生效、指向哪个入口，以及不用时如何撤销。