Mac代理已设，如何让特定网站走代理而其余直连？

Question

在 macOS 系统已全局配置（如系统偏好设置 → 网络 → 代理）或通过 Proxyman/Charles/SwitchyOmega 等工具启用代理的前提下，用户常遇到一个典型问题：**如何实现“智能分流”——仅让特定域名（如 api.example.com、dev.internal）走代理，其余流量直连，避免影响日常访问速度与企业内网连通性？** 该需求无法通过 macOS 原生的“自动代理配置（PAC）”开关直接满足，因其仅支持“全部代理”或“全部直连”二选一；而手动配置 HTTP/HTTPS/SOCKS 代理又会强制全局生效。常见误区是误以为开启“自动代理配置 URL”后只需写简单 if-else 就能生效，实则 PAC 文件语法严格、调试困难，且 Safari/Firefox/Chrome 对 PAC 的缓存与解析行为不一致。此外，macOS 13+ 对 PAC 的 TLS 要求升级，本地 file:// 协议被禁用，进一步增加部署门槛。如何安全、稳定、跨浏览器地实现基于域名/路径/IP 的细粒度代理分流，是开发者和测试工程师高频痛点。

Answer 1

```html

一、问题本质剖析：为什么 macOS 原生代理无法实现“智能分流”？

macOS 网络偏好设置中的「自动代理配置（PAC）」看似支持条件逻辑，实则受限于系统级 PAC 引擎（CFNetwork）的解析能力与策略隔离机制。其核心矛盾在于：

• 系统级 PAC 仅作用于 HTTP/HTTPS 流量，对 DNS、QUIC、WebSockets、gRPC、mTLS 流量无感知；
• PAC 脚本中 dnsResolve() 在 macOS 13+ 被沙盒严格限制，无法解析内部域名（如 dev.internal）；
• Safari 使用 WebKit 内置 PAC 解析器（缓存强、更新延迟 >30s），Chrome/Firefox 则各自实现（Chromium 复用系统 PAC，Firefox 可绕过）；
• file:// 协议在 macOS 13+ 被完全禁用，导致本地调试 PAC 文件失败，必须部署 HTTPS 服务且证书可信。

二、技术路径对比：四种主流智能分流方案能力矩阵

方案	是否需 root	支持域名/IP/路径匹配	跨浏览器一致性	支持 TLS 拦截（MITM）	运维复杂度
PAC（HTTPS 托管）	否	✅ 域名/子域（shExpMatch）	⚠️ Safari/Chrome 差异显著	❌ 不介入连接建立	高（证书+CDN+缓存治理）
Proxyman/Charles 的「Rules」引擎	否	✅ 域名/路径/Method/Header/Body 正则	✅ 仅限其自身代理端口（需全局设为 127.0.0.1:9090）	✅ 全链路 MITM	低（GUI 配置即生效）
Clash for Mac（TUN 模式）	✅ 是（首次启用需授权）	✅ Domain, IP-CIDR, GEOIP, Rule-Provider, Script	✅ 系统级劫持，全流量统一策略	✅ 可配合 mitm-config 实现 TLS 解密	中（YAML 规则需维护，但社区模板丰富）
dnsmasq + ipfw/pf + proxy（自建网关）	✅ 是	✅ DNS 分流 + IP 层标记 + iptables 重定向	✅ 所有应用无感（含 curl/wget/IDE 内置 HTTP 客户端）	⚠️ 需额外部署 SSL bumping 代理（如 Squid + ssl-crtd）	高（网络栈深度耦合，升级风险大）

三、推荐实践：Clash for Mac TUN 模式 + 自定义规则集（生产就绪）

针对 5 年以上经验工程师，我们推荐采用 Clash for Mac v1.10+ 的 TUN 模式——它规避了 PAC 的全部缺陷，同时提供企业级分流能力：

1. 安装后启用「TUN Mode」并授予 Full Disk Access 权限；
2. 配置 rule-providers 动态加载远程规则（如 GitHub Gist 或私有 GitLab）；
3. 关键规则示例（支持通配符、正则、IP 段、GEOIP）：

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - DOMAIN,api.example.com,PROXY
  - DOMAIN-KEYWORD,dev,PROXY
  - IP-CIDR,10.0.0.0/8,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH, DIRECT

四、进阶调试：如何验证分流是否真正生效？

避免“以为走代理实则直连”的陷阱，建议组合使用以下命令验证：

• scutil --proxy：查看当前系统代理状态（注意：TUN 模式下此处显示为空，属正常）；
• tcpdump -i en0 host api.example.com and port 443：确认目标域名 TLS 握手是否发往代理 IP（如 127.0.0.1 或 192.168.x.x）；
• curl -v https://api.example.com --resolve 'api.example.com:443:127.0.0.1' 2>&1 | grep "Connected to"：强制解析+代理路径验证；
• 在 Proxyman 中开启「Show System Traffic」并过滤 api.example.com，观察请求是否出现。

五、架构演进图：从 PAC 到零信任代理网关

graph LR
  A[传统 PAC] -->|局限：仅 HTTP/Safari 缓存顽固| B[Clash TUN]
  B -->|增强：eBPF 支持+EBPF_HOOK| C[Clash Meta]
  C -->|集成：OPA 策略引擎+SPIFFE 身份认证| D[Zero-Trust Proxy Gateway]
  D --> E[基于 SVID 的 mTLS 双向认证]
  D --> F[动态策略下发 via Istio Control Plane]

六、安全加固要点（面向资深工程师）

当代理成为基础设施组件，必须关注以下纵深防御措施：

• 禁止将 PAC URL 或 Clash 配置托管于公网可读 GitHub 仓库（敏感域名泄露风险）；
• Clash 配置中启用 external-controller: 127.0.0.1:9090 并配合 authentication 防止未授权策略变更；
• 对 dev.internal 类内网域名，优先使用 DNS over HTTPS（DoH）+ fake-ip-filter 避免 DNS 泄漏；
• 定期审计 system_profiler SPNetworkDataType | grep -A 10 "Proxies" 输出，防止其他工具（如某些 VPN 客户端）覆盖代理设置。

七、兼容性避坑清单（macOS 13–14 实测）

• ❌ 不要使用 isInNet(dnsResolve(host), "10.0.0.0", "255.0.0.0") —— dnsResolve() 在 macOS 13+ 返回空字符串；
• ✅ 替代方案：用 shExpMatch(host, "*.internal") || shExpMatch(host, "dev.*")；
• ❌ Chrome 119+ 默认禁用不安全 PAC（HTTP），必须使用 HTTPS + Apple 根证书信任链；
• ✅ 推荐 PAC 托管方式：Cloudflare Pages + 自签名证书导入钥匙串（类型：系统）+ 设置「始终信任」。

```