iPhone的“自动代理”不是自动寻找代理服务器，而是让当前Wi-Fi下载一份代理自动配置文件，也就是PAC文件。PAC文件通过规则判断某个HTTP或HTTPS请求应走指定代理，还是直接连接。设置时应填写PAC文件的完整URL，而不是代理节点的IP、端口或订阅文本。
最重要的边界是：iPhone Wi-Fi自动代理只针对当前保存的无线网络配置，不会自动覆盖蜂窝数据，也不能把SOCKS5节点地址直接当成PAC URL。如果需求是所有App、UDP流量或移动数据统一改出口，单靠这个开关通常不够。
先分清手动代理与自动代理
| 项目 | 手动代理 | 自动代理 |
|---|---|---|
| 填写内容 | 服务器、端口，必要时填写认证信息 | 一条PAC文件URL |
| 路由规则 | 通常将兼容流量交给同一代理 | 由PAC按域名、主机或其他条件决定代理与直连 |
| 变更方式 | 换节点时要修改设备配置 | 维护者更新PAC后，设备重新获取规则 |
| 常见用途 | 单节点、临时测试 | 办公网络、按域名分流、集中维护 |
| 共同限制 | 都绑定当前Wi-Fi；App是否采用系统HTTP代理仍需逐个验证 | |
自动代理的核心不是“更强”，而是“规则可集中维护”。如果服务方只给出一条代理IP和端口，却没有提供PAC地址，就不能凭空把节点信息变成自动代理URL。
iPhone自动代理URL设置步骤
- 连接要配置的Wi-Fi，打开“设置”并进入“无线局域网”。
- 点击当前Wi-Fi右侧的信息按钮，向下找到“配置代理”。
- 选择“自动”，在URL字段填写完整地址，例如以
https://开头的PAC文件地址。 - 返回上一页保存配置。为避免旧连接继续复用，可关闭并重新打开相关App；必要时断开并重新连接该Wi-Fi。
- 先用浏览器访问一个明确应走代理的检测目标，再测试实际使用的App。
菜单名称会随系统语言和版本略有变化，但判断标准不变：配置对象应是当前Wi-Fi，模式应是“自动”，字段内容应是一条能返回PAC脚本的URL。
PAC文件究竟返回什么
PAC文件本质上包含一个名为FindProxyForURL(url, host)的JavaScript函数。系统把请求URL和主机名交给函数，函数返回处理方式。常见结果包括：
DIRECT：不经过代理，直接访问目标；PROXY proxy.example:8080：交给指定HTTP代理；- 多个结果按顺序排列：前一个不可用时再尝试后一个，最后可设置直连回退。
规则可以按域名、子域名、主机名或网络条件分流。例如公司内网域名直连，指定外部业务走代理。PAC不是普通的IP列表，也不是把所有代理协议封装到一个文件中的通用订阅格式。
怎样判断PAC地址本身可用
配置前先检查四件事：
- URL可访问：手机在未启用代理时也能获取该文件，不能依赖尚未建立的代理才能下载。
- 返回的是PAC脚本：打开后不应是登录页、验证码、HTML错误页或网盘分享页。
- 地址稳定：短时签名链接、一次性下载链接或随时失效的临时地址不适合长期配置。
- 传输可信：优先使用可信HTTPS来源，避免规则在传输途中被替换；不要在公开URL中裸露代理密码。
如果PAC文件需要网页登录后才能获取，iPhone后台重新拉取时可能得不到相同内容。企业或团队环境还要考虑证书信任、文件权限和变更回滚。
为什么设置成功后IP仍然没变
“能保存配置”只证明字段格式被接受，不代表所有流量已经经过代理。常见原因可以按下面的顺序排查。
PAC规则返回了DIRECT
目标域名没有命中代理条件，或者规则把内网、局域网和特定后缀设为直连。用另一个明确应命中的测试域名对照，能快速区分规则问题与代理节点问题。
App没有采用系统HTTP代理
部分App使用自定义网络栈、直接Socket、QUIC或其他传输方式，不一定遵循Wi-Fi里的HTTP代理设置。浏览器出口改变而某个App不变，通常应先检查App的网络实现和代理支持范围，而不是反复修改PAC URL。
手机已经切到蜂窝数据
Wi-Fi信号弱、无线局域网助理或用户手动切换网络时，请求可能不再走该Wi-Fi。测试时应确认状态栏网络，并分别记录Wi-Fi和蜂窝数据的结果。
IPv6或旧连接造成结果不一致
代理只处理部分IPv4请求，而应用仍可通过IPv6直连；已经建立的长连接也可能继续使用旧出口。关闭App重开、重新连接Wi-Fi，并分别检查IPv4和IPv6，才能判断配置覆盖范围。
PAC缓存尚未刷新
系统可能缓存已获取的PAC文件。刚修改服务器端规则时，不宜只刷新网页就断言更新失败。可重新连接Wi-Fi或暂时切换代理模式后再恢复自动，并确认文件URL返回的是新内容。生产环境修改规则时应保留旧版本，避免一次错误让所有设备失去连接。
按三层结果验收，而不是只查一次IP
- 配置层：当前Wi-Fi显示自动代理，URL没有拼写错误，PAC文件可从手机网络访问。
- 规则层：选择一个应走代理的域名和一个应直连的域名，确认二者行为符合设计。
- 应用层：分别测试Safari和实际App，记录IPv4、IPv6、DNS、长连接和网络切换后的表现。
如果手动HTTP代理可用、自动代理不可用，重点检查PAC文件和规则；如果两种模式都失败，重点检查代理地址、端口、认证、网络可达性和协议。若需要先复习苹果手机手动设置和停用方法，可阅读极跃圈的iPhone Wi-Fi代理设置与失效排查。
自动代理不适合哪些需求
- 希望蜂窝数据和所有Wi-Fi统一使用同一出口；
- 应用主要依赖UDP、游戏实时流量或不采用系统HTTP代理；
- 服务方只提供SOCKS5节点，没有HTTP代理或PAC支持；
- 需要按进程、账号或容器做强隔离；
- 无法控制PAC文件托管、证书和版本变更。
这些场景需要评估受信任的客户端、VPN类接入、路由器分流或应用内代理。选择方案前应先确认合法授权、协议兼容和数据处理边界，不要把“自动”理解为自动覆盖所有网络活动。
结论
iPhone自动代理URL应填写可直接获取的PAC文件地址。PAC通过FindProxyForURL为请求返回代理或直连规则，适合当前Wi-Fi下的HTTP/HTTPS分流和集中维护。验证时必须同时检查PAC可访问性、规则命中、App是否遵循系统代理、蜂窝数据、IPv6与缓存；只看到某次IP查询变化，不能证明所有流量都已按规则转发。
