一、引言，为什么 Surge 被誉为 Apple 生态下网络协议调试工具的标杆
在 Apple 生态的网络调试与代理转发领域，Surge 从 2015 年发布至今，始终占据着一个特殊位置。它既被大量网络工程师当作 macOS 与 iOS 上的抓包分析工具，也被企业出海运维团队用作跨境流量的策略调度中枢。要理解这个定位，需要从它在协议栈中的实际工作层面谈起。
Surge 在 macOS 上以 Network Extension 框架运行，通过 NEPacketTunnelProvider 创建虚拟网卡接口，接管系统层面的 IP 数据包。当一条 TCP SYN 包从应用层发出，目标地址匹配到 Surge 的规则集时，内核会将数据包重定向至 utun 接口，Surge 在此完成连接建立、TLS 握手解析、HTTP 头部读取，再根据策略组决定转发路径。整个过程对上层应用完全透明，浏览器、终端、甚至 Docker 容器内的进程都无需配置任何代理环境变量。
这与传统的 HTTP 代理工具存在本质差异。以 Charles 或 mitmproxy 为例，它们工作在应用层，依赖应用主动将流量发往代理端口，对不遵循系统代理设置的进程无能为力。Surge 的增强模式（Enhanced Mode）则通过 utun 虚拟接口截获所有出站流量，包括那些硬编码 IP 直连的程序。在 macOS 上，Surge 会安装一个系统扩展来创建这个虚拟接口，配合 pf 防火墙规则将流量引流至 Surge 进程。这意味着即使某个 CLI 工具使用原始 socket 连接，流量依然会经过 Surge 的规则引擎。
从数据包处理能力来看，Surge 支持完整的 HTTP/1.1、HTTP/2、HTTP/3（QUIC）解析，以及 TLS 1.2 和 TLS 1.3 的中间人解密。在 TLS 解密场景下，Surge 会动态生成证书链，将原始服务器的证书信息完整呈现给用户。以 TLS 1.3 为例，Surge 需要处理 EncryptedExtensions、Certificate、CertificateVerify、Finished 等握手消息，并支持 HelloRetryRequest 流程。抓包视图中可以看到每个请求的完整时间线分解，包括 DNS 查询耗时、TCP 连接建立耗时、TLS 握手耗时、首字节到达时间（TTFB）以及内容下载耗时。这些数据对于诊断跨境链路质量至关重要，例如判断某个机场节点的延迟瓶颈究竟出现在 DNS 解析阶段还是 TLS 握手阶段。
Surge 的配置文件采用类 INI 的段落式结构，分为 [General]、[Proxy]、[Proxy Group]、[Rule] 等区块。一个典型的策略组配置如下。
[Proxy Group]Auto = url-test, ProxyA, ProxyB, ProxyC, url = http://www.gstatic.com/generate_204, interval = 300, tolerance = 50Fallback = fallback, ProxyA, ProxyB, url = http://www.gstatic.com/generate_204, interval = 300LoadBalance = load-balance, ProxyA, ProxyB, ProxyC, url = http://www.gstatic.com/generate_204, interval = 300url-test 类型会以指定 URL 为探测目标，每 300 秒对组内节点发起一次 HTTP HEAD 请求，测量完整请求耗时，并自动切换到延迟最低的节点。tolerance 参数设置为 50 毫秒，意味着只有当新节点比当前节点快超过 50 毫秒时才会触发切换，避免在延迟相近的节点之间频繁抖动。fallback 类型则按顺序探测，始终使用第一个可用节点。load-balance 类型在组内节点间做一致性哈希分发，适合多线程下载场景。
规则系统是 Surge 的另一核心。规则类型包括 DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、IP-CIDR6、GEOIP、USER-AGENT 等。匹配顺序自上而下，一旦命中即执行对应策略。以 GEOIP 规则为例，Surge 内置了 MaxMind 的 GeoLite2 数据库，通过查询目标 IP 的注册地信息来决定分流。对于企业出海场景，可以配置如下规则集。
[Rule]DOMAIN-SUFFIX,internal.company.com,DIRECTIP-CIDR,10.0.0.0/8,DIRECT,no-resolveIP-CIDR,172.16.0.0/12,DIRECT,no-resolveGEOIP,CN,DIRECTDOMAIN-SUFFIX,openai.com,ProxyDOMAIN-SUFFIX,github.com,ProxyFINAL,Proxy其中 no-resolve 参数指示 Surge 在匹配 IP 规则时不要触发 DNS 解析，直接使用连接目标 IP 进行判断。这对于内网地址段尤为关键，避免将内网域名泄露到公共 DNS。GEOIP,CN 规则会将所有解析到中国大陆 IP 的流量直连，其余流量走代理。FINAL 规则作为兜底，处理所有未匹配流量。
Surge 的模块系统（Module）进一步扩展了配置能力。模块以 .sgmodule 为后缀，可以覆盖 General 设置、注入 MITM 主机名、添加规则和脚本。例如，一个用于解锁流媒体区域的模块可能包含 MITM 主机名列表和对应的 HTTP 重写规则。模块的加载优先级高于主配置，多个模块之间按加载顺序叠加。这使得团队可以维护一套基础配置，再通过模块按需叠加不同功能，例如广告拦截、隐私保护、特定服务解锁等。
在企业级场景中，Surge 的 HTTP API 提供了外部控制能力。通过开启 [General] 中的 http-api 参数，可以指定监听地址和密钥。
[General]http-api = 0.0.0.0:6171http-api-tls = true随后可通过 RESTful 接口查询当前策略组状态、切换节点、获取流量统计。例如发送 GET /v1/policy_groups 可获取所有策略组的当前选中节点和延迟数据。运维人员可以将这些接口接入 Prometheus 或自建监控面板，实现对跨境链路质量的实时感知。当某个专线节点延迟超过阈值时，自动化脚本可以调用 API 切换策略，或触发告警通知。
Surge 的抓包能力同样值得展开。在 macOS 版本中，开启抓包后，Surge 会记录每个 HTTP 事务的完整请求和响应头，支持按域名、状态码、方法过滤。对于 HTTPS 流量，在安装并信任 Surge 的根证书后，可以解密查看明文内容。证书安装流程涉及将 Surge 生成的 CA 证书导入系统钥匙串，并在钥匙串访问中将其信任级别设置为“始终信任”。在 iOS 上，还需要在“关于本机”的证书信任设置中手动启用完全信任。这套流程虽然步骤较多，但一旦配置完成，就能在移动设备上实现与桌面端一致的调试体验。
从性能角度看，Surge 在 M 系列芯片的 Mac 上处理千兆带宽流量时，CPU 占用通常维持在个位数百分比。这得益于其底层使用 Swift 和 Objective-C 混合编写，网络 IO 采用 kqueue 事件驱动模型，避免了轮询带来的额外开销。在内存占用方面，常规使用场景下约在 100MB 至 200MB 之间，具体取决于规则集大小和并发连接数。
Surge 的规则集可以引用远程 URL，并支持定时更新。远程规则集采用纯文本格式，每行一条规则，Surge 会按配置的 interval 自动拉取最新版本。这对于需要动态调整分流策略的团队非常实用，例如将某个新上线的服务域名快速加入代理列表，只需更新远程规则文件，所有客户端会在下一个更新周期自动生效。
综合来看，Surge 在 Apple 生态中的标杆地位建立在几个技术事实之上。它工作在网络层，通过虚拟网卡接管全部流量；它完整解析 HTTP/2 和 TLS 1.3，提供细粒度的抓包与调试视图；它的策略组引擎支持 url-test、fallback、load-balance 等多种调度算法；它的规则系统覆盖域名、IP、GeoIP、User-Agent 等维度；它的模块机制和 HTTP API 为团队协作与自动化运维提供了扩展点。对于需要精细控制跨境流量的网络工程师和企业运维人员，Surge 提供的控制粒度和可观测性，在当前 Apple 生态的代理工具中依然难以被替代。
若需进一步了解不同机场服务在 Surge 下的实际表现，可参阅 机场评测中心深度对比大全 中的延迟与丢包测试数据。对于刚接触 Surge 的读者，配置教程保姆级指南 提供了从安装到规则编写的完整步骤。在选择底层网络服务时，2026 优质稳定高速机场推荐总榜 汇总了当前可用的专线资源，而 专线百科 则详细解释了 IEPL、IPLC 等专线类型的协议差异。对于关注服务稳定性的用户，科学上网防跑路避坑指南 整理了识别高风险服务商的实用方法。
二、Surge 配置文件整体骨架，General、Proxy、Proxy Group 与 Rule
Surge 的配置文件本质是一个纯文本的键值结构描述文件，采用 INI 风格的节区（Section）划分。一个可运行的配置至少包含四个核心节区，它们分别是 [General]、[Proxy]、[Proxy Group] 和 [Rule]。这四个节区共同构成了 Surge 流量调度的完整决策链，从全局行为参数到出口节点定义，再到策略聚合与最终分流规则，层层递进。理解它们之间的引用关系与求值顺序，是编写高性能、可维护配置的前提。
2.1 General 节区，全局行为与网络栈参数
[General] 节区定义 Surge 进程的全局运行参数，影响所有后续节区的行为。它不参与流量匹配，但决定了匹配发生时的底层网络行为。常见的键值对包括 loglevel、dns-server、encrypted-dns-server、ipv6-vif、tun-excluded-routes、wifi-assist 等。
以 DNS 配置为例，dns-server 指定系统 DNS 解析器，而 encrypted-dns-server 则启用 DoH 或 DoT。当两者同时存在时，Surge 优先使用加密 DNS 进行解析，并将结果缓存至本地 DNS 缓存表。缓存 TTL 遵循 DNS 响应中的 TTL 字段，但 Surge 允许通过 dns-cache-ttl 强制覆盖，单位为秒。对于企业出海场景，建议将 dns-server 设置为内部 DNS 或可信公共解析器，例如 223.5.5.5 与 119.29.29.29，同时启用 encrypted-dns-server = https://doh.pub/dns-query 以规避 DNS 污染。
另一个关键参数是 ipv6-vif，它控制 TUN 接口是否启用 IPv6 虚拟接口。取值 off、auto 或 always。在纯 IPv4 企业内网中，设为 off 可避免 IPv6 路由表污染。若设为 auto，Surge 仅在检测到 IPv6 连通性时启用。tun-excluded-routes 则用于排除特定网段，使其不经过 TUN 接口，例如 tun-excluded-routes = 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16，这在同时连接企业 VPN 时尤为必要，可防止内网流量被错误代理。
wifi-assist 参数控制是否允许蜂窝网络辅助 Wi-Fi，取值 true 或 false。在移动场景下，设为 true 可提升弱网切换体验，但可能增加蜂窝数据消耗。loglevel 支持 verbose、info、notify、warning 等级别，生产环境建议使用 warning 以减少日志 I/O 开销。
2.2 Proxy 节区，出口节点的原子定义
[Proxy] 节区定义所有可用的代理节点，每个节点是一个独立的键值对，键为节点名称，值为协议类型与参数。Surge 支持的协议包括 http、https、socks5、ss、vmess、trojan、snell、wireguard 等。以 Shadowsocks 为例，典型定义如下。
[Proxy]HK-01 = ss, hk01.example.com, 443, encrypt-method=aes-256-gcm, password=YOUR_PASSWORD, udp-relay=trueUS-01 = vmess, us01.example.com, 443, username=uuid-here, ws=true, ws-path=/ws, tls=true, sni=us01.example.comJP-01 = trojan, jp01.example.com, 443, password=YOUR_PASSWORD, sni=jp01.example.com, skip-cert-verify=false每个节点可携带多个可选参数。udp-relay=true 启用 UDP 中继，对于需要 QUIC、DNS over UDP 或游戏流量的场景至关重要。tls=true 与 sni 组合用于 TLS 握手时的 SNI 指定，skip-cert-verify 控制是否跳过证书验证，生产环境应始终设为 false 以防御中间人攻击。ws=true 与 ws-path 用于 WebSocket 传输层，ws-headers 可附加自定义 HTTP 头，例如 ws-headers=Host:cdn.example.com|User-Agent:Surge。
节点定义中的域名解析发生在 Surge 启动或配置重载时。若域名解析失败，该节点会被标记为不可用，但不会导致整个配置加载失败。Surge 支持 resolve-on-proxy 参数，将该节点的域名解析交由代理服务器完成，适用于 DNS 污染严重的环境。此时本地仅解析代理服务器地址，目标域名以域名形式传递给代理，由代理端进行解析。
2.3 Proxy Group 节区，策略聚合与故障转移
[Proxy Group] 节区将多个 [Proxy] 节点聚合为一个逻辑策略组，供 [Rule] 节区引用。策略组支持多种类型，包括 select、url-test、fallback、load-balance、ssid 等。每种类型的行为差异显著，直接影响流量调度结果。
select 类型提供手动选择，用户可通过 Surge 界面或 HTTP API 切换节点。url-test 类型定期向指定 URL 发起探测，自动选择延迟最低的节点。探测间隔由 interval 参数控制，默认 600 秒，最小 60 秒。tolerance 参数定义切换阈值，单位为毫秒，默认 100 毫秒，即新节点延迟需低于当前节点至少 100 毫秒才会触发切换。fallback 类型按顺序探测，选择第一个可用的节点，适用于主备切换场景。load-balance 类型按轮询或随机方式分配流量，适用于多节点负载均衡。
以下是一个典型的多策略组配置。
[Proxy Group]Auto = url-test, HK-01, HK-02, US-01, url=http://www.gstatic.com/generate_204, interval=300, tolerance=50Fallback = fallback, HK-01, US-01, JP-01, url=http://www.gstatic.com/generate_204, interval=300Manual = select, Auto, Fallback, HK-01, US-01, DIRECTStreaming = select, US-01, JP-01, DIRECTAuto 组每 300 秒探测一次，容差 50 毫秒。Fallback 组按顺序探测，优先使用 HK-01，不可用时切换至 US-01。Manual 组嵌套了 Auto 和 Fallback，形成层级策略，这是 Surge 配置中常见的复用模式。嵌套策略组时，Surge 会递归求值，但需避免循环引用，否则配置加载会报错。
策略组的探测流量本身也受规则约束。默认情况下，探测请求直接发出，不经过代理。若需通过代理探测，可添加 via 参数指定中间策略组。探测 URL 建议使用返回 204 的轻量端点，例如 http://www.gstatic.com/generate_204 或 http://cp.cloudflare.com/generate_204，以减少带宽消耗。
2.4 Rule 节区，分流决策的最终执行
[Rule] 节区是 Surge 流量调度的核心，每条规则由类型、匹配条件和目标策略三部分组成。规则按从上到下的顺序求值，首条匹配的规则生效，后续规则不再评估。规则类型包括 DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、IP-CIDR6、GEOIP、USER-AGENT、PROCESS-NAME、RULE-SET 等。
DOMAIN 精确匹配完整域名，DOMAIN-SUFFIX 匹配域名后缀，DOMAIN-KEYWORD 匹配域名中的关键词。IP-CIDR 匹配目标 IP 网段，可附加 no-resolve 参数，表示不触发 DNS 解析，仅对已知 IP 进行匹配。GEOIP 基于 IP 地理位置数据库匹配国家代码，例如 GEOIP,CN,DIRECT 将中国大陆 IP 直连。RULE-SET 引用外部规则集，支持 rule-set 文件或远程 URL，大幅简化配置维护。
以下是一个企业级分流规则片段。
[Rule]DOMAIN-SUFFIX,internal.example.com,DIRECTIP-CIDR,10.0.0.0/8,DIRECT,no-resolveIP-CIDR,172.16.0.0/12,DIRECT,no-resolveDOMAIN-SUFFIX,office365.com,ManualDOMAIN-SUFFIX,slack.com,ManualDOMAIN-SUFFIX,github.com,AutoDOMAIN-KEYWORD,google,AutoGEOIP,CN,DIRECTRULE-SET,https://example.com/ruleset/proxy.list,AutoMATCH,Fallback规则求值顺序至关重要。企业内网域名与私有 IP 网段应置于顶部，确保直连。办公协作类域名指向 Manual 组，便于手动切换出口。开发类域名指向 Auto 组，享受自动延迟优选。GEOIP,CN,DIRECT 将中国大陆 IP 直连，减少代理负载。RULE-SET 引用远程规则集，适合大规模域名列表的动态更新。MATCH 是兜底规则，必须位于最后，匹配所有未命中流量。
no-resolve 参数在 IP-CIDR 规则中尤为重要。当规则匹配目标 IP 时，若未加 no-resolve，Surge 会先对域名进行 DNS 解析，再将解析结果与 CIDR 比对。这会导致额外的 DNS 查询延迟，并可能因 DNS 污染导致误判。对于已知私有网段，始终添加 no-resolve 可避免不必要的解析开销。
规则集的远程加载支持 interval 参数，控制更新频率。默认 86400 秒，即每天更新一次。更新失败时，Surge 保留上一次成功加载的规则集，确保服务连续性。规则集文件格式为纯文本，每行一条规则，与 [Rule] 节区语法一致，但不包含目标策略，策略在引用时指定。
2.5 节区引用关系与求值顺序
四个节区的引用关系构成一个有向无环图。[General] 定义全局参数，不参与引用。[Proxy] 定义原子节点。[Proxy Group] 引用 [Proxy] 中的节点或其他策略组。[Rule] 引用 [Proxy Group] 或 [Proxy] 中的节点，也可直接使用 DIRECT 或 REJECT 内置策略。
求值顺序发生在每个连接建立时。Surge 首先根据 [General] 中的 DNS 配置解析目标域名，然后按 [Rule] 顺序逐条匹配。匹配到规则后，提取目标策略。若目标策略是策略组，则根据策略组类型进行节点选择。若策略组是 url-test，则使用最近一次探测结果；若探测尚未完成，则使用配置中的第一个节点作为初始选择。最终，流量通过选定的节点或直连出口发出。
这一求值链的每个环节都可通过日志观察。将 loglevel 设为 verbose 后，Surge 会输出每条连接的规则匹配详情、DNS 解析结果、策略组选择依据以及最终出口节点。对于排查分流异常，这是最直接的手段。企业运维人员可结合 HTTP API 的 /v1/requests 端点，实时获取连接列表与规则命中信息，实现自动化监控与告警。
理解这四个节区的骨架，是编写任何 Surge 配置的起点。后续章节将深入策略组的高级用法、模块化规则集管理以及企业级分流实战。对于希望验证不同机场节点在真实规则下的表现，可参考 机场评测中心深度对比大全 中的延迟与丢包数据。若需从零开始搭建配置，配置教程保姆级指南 提供了逐步操作说明。选择底层网络服务时，2026 优质稳定高速机场推荐总榜 汇总了当前可用的专线资源，而 专线百科 则解释了 IEPL、IPLC 等专线类型的协议差异。对于关注服务稳定性的用户，科学上网防跑路避坑指南 整理了识别高风险服务商的实用方法。
三、策略组（Proxy Group）高级设计，Url-Test、Fallback 与 Load-Balance 策略
在 Surge 的配置体系中，策略组承担着将多个出站节点聚合为一个逻辑出口的职责。基础用法里，select 类型让用户手动切换节点，url-test 则自动挑选延迟最低的节点。当配置规模上升到数十个节点、多条专线、多个地域出口时，策略组的设计质量直接决定了故障切换速度、带宽利用率和排障效率。本章围绕 url-test、fallback、load-balance 三种自动策略展开，剖析其探测机制、参数语义与生产环境中的组合范式。
3.1 健康检查的底层机制
三种自动策略共享同一套健康检查框架。Surge 以固定间隔向目标 URL 发起 HTTP HEAD 或 GET 请求，测量从发出请求到收到响应首字节的耗时，即 TTFB（Time To First Byte）。该耗时包含 DNS 解析、TCP 三次握手、TLS 握手（若为 HTTPS）以及服务端处理时间。默认探测间隔为 600 秒，可通过 interval 参数调整，单位为秒。
探测请求的报文结构值得展开。以 HTTP/1.1 为例，Surge 发出的请求头大致如下，
HEAD /generate_204 HTTP/1.1Host: www.gstatic.comUser-Agent: Surge/5.xAccept: */*Connection: close选择 generate_204 这类返回 204 No Content 的端点，是因为响应体为空，TTFB 几乎等于网络往返时间（RTT），能更纯粹地反映链路质量。若目标返回 200 且带有响应体，测量值会混入服务端渲染或传输耗时，导致延迟数据偏高。企业环境中也可自建探测端点，部署在就近的 IDC，返回固定大小的响应体，以获得更可控的基准。
超时判定由 timeout 参数控制，默认 5 秒。若在超时窗口内未收到响应，该节点被标记为不可用。连续失败次数达到阈值后，节点从策略组的可用集合中移除。恢复探测同样按 interval 周期进行，一旦某次探测成功，节点重新加入可用集合。
这里有一个容易被忽视的细节。Surge 的健康检查走的是节点自身的代理链路，而非直连。这意味着探测延迟反映的是“客户端→代理服务器→目标 URL”的端到端耗时，而非单纯的节点入口 RTT。对于 IEPL 专线节点，探测延迟通常比入口 ping 值高出 20 至 80 毫秒，差额来自专线出口到目标 URL 的公网段。理解这一点，有助于在对比不同机场时建立正确的预期。关于专线类型的协议差异，可参阅 专线百科 中的详细说明。
3.2 url-test 策略的参数调优
url-test 的核心行为是周期性地对所有可用节点发起探测，然后将流量导向延迟最低的那个节点。基础配置如下，
[Proxy Group]Auto = url-test, node1, node2, node3, url = http://www.gstatic.com/generate_204, interval = 300, tolerance = 50tolerance 参数是调优的关键。它的单位是毫秒，默认值为 0。当 tolerance 设为 50 时，如果当前选中节点的延迟为 120ms，而另一个节点探测结果为 100ms，两者差值 20ms 小于 tolerance 阈值，Surge 不会切换节点。只有当候选节点的延迟比当前节点低出超过 50ms 时，才会触发切换。这个机制避免了因网络抖动导致的频繁切换，在跨境链路中尤为重要。实测数据表明，中美链路在晚高峰时段的 RTT 抖动可达 30 至 60ms，若 tolerance 设为 0，策略组可能每隔几分钟就切换一次节点，造成 TCP 连接中断和应用层重连。
interval 的设置需要权衡。间隔过短，比如 60 秒，探测流量本身会消耗带宽，对于按流量计费的节点尤为不利。间隔过长，比如 1800 秒，故障发现延迟增大，用户可能在不稳定的节点上忍受数分钟。生产环境中，300 秒是一个较为均衡的选择。对于企业级部署，可结合 Surge 的 HTTP API 实现外部监控，当探测延迟超过阈值时主动触发告警，而非单纯依赖策略组的自动切换。
url-test 还有一个隐藏行为。当策略组内所有节点都探测失败时，Surge 会回退到组内第一个节点，而非直接拒绝连接。这个设计保证了极端情况下的可用性，但也意味着用户可能在不知情的情况下使用了一个已经失效的节点。因此，配合外部监控是必要的。
3.3 fallback 策略的故障转移语义
fallback 策略组的行为逻辑与 url-test 有本质区别。它维护一个优先级列表，始终使用列表中第一个可用节点。只有当第一个节点探测失败时，才切换到第二个，依此类推。配置示例如下，
[Proxy Group]Fallback = fallback, primary, secondary, backup, url = http://www.gstatic.com/generate_204, interval = 300这种策略适用于对节点稳定性要求极高、但对延迟不敏感的场景。比如企业跨境办公中，主链路是一条 IEPL 专线，备用链路是 IPLC 或高质量的 BGP 中转。日常流量走主链路，主链路故障时自动切换到备用链路。由于 fallback 不做延迟比较，不会因为备用链路延迟更低就主动切换，从而保证了出口 IP 的稳定性。这一点在需要固定出口 IP 的业务中至关重要，比如访问带有 IP 白名单的 SaaS 服务或银行接口。
fallback 的探测失败判定同样依赖 timeout 和连续失败次数。需要注意的是，探测失败并不等同于链路完全中断。某些节点可能对 generate_204 端点限速或屏蔽，但实际业务流量仍可正常通过。这种情况下，可以通过自定义探测 URL 来规避。例如，将探测目标改为企业内网的一个健康检查端点，或改为目标业务系统的登录页面。
3.4 load-balance 策略的流量分配
load-balance 策略组将流量分散到多个节点上，适用于需要聚合带宽或分散连接数的场景。Surge 支持两种分配模式，round-robin 和 random。配置示例如下，
[Proxy Group]Balance = load-balance, node1, node2, node3, url = http://www.gstatic.com/generate_204, interval = 300, strategy = round-robinround-robin 按顺序轮流使用节点，每个新连接分配到下一个可用节点。random 则随机选择。两种模式都基于连接级别分配，而非包级别。这意味着同一个 TCP 连接的所有数据包始终走同一个节点，不会出现乱序问题。对于 HTTP/2 或 QUIC 这类多路复用协议，多个流可能分布在不同的 TCP 连接上，从而被分配到不同节点，实现一定程度的并行加速。
load-balance 的局限性在于，它无法感知各节点的实际带宽负载。如果三个节点中有一个是 100Mbps 独享，另外两个是 50Mbps 共享，轮询分配会导致共享节点过载。因此，load-balance 更适合节点质量相近的场景。对于质量差异较大的节点池，建议先用 url-test 筛选出低延迟节点，再将它们放入 load-balance 组。
3.5 嵌套策略组与生产环境范式
Surge 允许策略组嵌套引用其他策略组，这为复杂场景提供了极大的灵活性。一个典型的企业级配置范式如下，
[Proxy Group]# 第一层，按地域筛选HK = url-test, hk-01, hk-02, hk-03, url = http://www.gstatic.com/generate_204, interval = 300, tolerance = 50US = url-test, us-01, us-02, us-03, url = http://www.gstatic.com/generate_204, interval = 300, tolerance = 50JP = url-test, jp-01, jp-02, url = http://www.gstatic.com/generate_204, interval = 300, tolerance = 50
# 第二层，按用途聚合Streaming = fallback, US, JP, HK, url = http://www.gstatic.com/generate_204, interval = 300Work = fallback, HK, JP, url = http://www.gstatic.com/generate_204, interval = 300Global = load-balance, HK, US, JP, url = http://www.gstatic.com/generate_204, interval = 300, strategy = round-robin这个三层结构的设计意图清晰。第一层按地域聚合节点，每个地域内部用 url-test 自动选择最优节点。第二层按业务用途聚合地域组。Streaming 组优先使用美国节点以解锁流媒体内容，美国组全部失效时回退到日本，再回退到香港。Work 组优先使用香港节点以获得最低延迟，香港组失效时回退到日本。Global 组则将三个地域组做负载均衡，适用于大文件下载或需要聚合带宽的场景。
在规则节区中，可以针对不同域名或 IP 段引用不同的策略组，
[Rule]DOMAIN-SUFFIX,netflix.com,StreamingDOMAIN-SUFFIX,github.com,WorkDOMAIN-SUFFIX,openai.com,USIP-CIDR,10.0.0.0/8,DIRECTFINAL,Global这种设计的优势在于，当某个地域的节点集体故障时，只需修改该地域组的节点列表，上层策略组和规则无需变动。同时，通过 Surge 的 HTTP API 可以查询每个策略组的当前选中节点和探测延迟，便于自动化运维。关于配置文件的完整结构和规则节区的写法，配置教程保姆级指南 提供了从零开始的逐步说明。
3.6 策略组设计的常见陷阱
第一个陷阱是探测 URL 选择不当。部分节点对 gstatic.com 的 generate_204 端点做了屏蔽或限速，导致探测延迟虚高，策略组误判为不可用。建议准备多个探测 URL，或使用自建端点。第二个陷阱是 tolerance 设为 0，导致频繁切换。跨境链路的抖动是常态，tolerance 设为 30 至 80 毫秒是合理的。第三个陷阱是 load-balance 组中混入质量差异过大的节点，导致部分连接体验极差。第四个陷阱是忽略探测流量成本。对于按流量计费的节点，300 秒间隔、每次探测约 1KB 的流量，一天累计约 288KB，一个月约 8.6MB，单节点看似不多，但节点数量多时总量可观。
在选择底层节点服务时，策略组的效果高度依赖节点本身的质量。延迟数据、丢包率和专线类型是评估机场的核心指标，机场评测中心深度对比大全 提供了基于真实探测的横向对比数据。对于需要长期稳定运行的企业环境，2026 优质稳定高速机场推荐总榜 汇总了当前可用的专线资源，而 科学上网防跑路避坑指南 则从运营稳定性角度给出了识别高风险服务商的方法。策略组的设计再精妙，也无法弥补底层节点频繁失效带来的体验损失。
四、分流规则编写法则，Domain-Set、Rule-Set 与 GEOIP 的精准匹配优先级
Surge 的规则引擎采用线性匹配模型。一个 TCP 连接或 UDP 会话进入处理管线后，引擎从配置文件 [Rule] 段的第一行开始逐条比对，命中即执行对应策略并终止后续匹配。这个设计决定了规则顺序直接等同于优先级，排在前面的规则拥有绝对的话语权。理解这一点，是写出高效分流配置的前提。
Surge 支持的规则类型包括 DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、DOMAIN-SET、RULE-SET、IP-CIDR、IP-CIDR6、GEOIP、USER-AGENT、PROCESS-NAME、DEST-PORT、SRC-IP 等十余种。每种类型的匹配开销不同，DOMAIN 类规则在内存哈希表中完成 O(1) 查找，IP-CIDR 需要逐条进行位运算比对，GEOIP 则要查询内置的 MMDB 数据库。规则数量达到数千条时，匹配顺序对延迟的影响开始显现。
域名匹配的精度层级
DOMAIN 是全量精确匹配，DOMAIN,api.openai.com,Proxy 只命中完全一致的域名，不匹配任何子域。DOMAIN-SUFFIX 匹配域名后缀，DOMAIN-SUFFIX,openai.com,Proxy 会命中 api.openai.com、chat.openai.com、cdn.openai.com 以及 openai.com 本身。DOMAIN-KEYWORD 是子串匹配，DOMAIN-KEYWORD,openai,Proxy 会命中任何包含 openai 字符串的域名，包括 notopenai.example.com 这类误伤目标。
三者的匹配开销依次递增。精确匹配走哈希表，后缀匹配需要从域名末尾逐段回溯，关键字匹配则要对整个域名字符串做子串搜索。在规则条数超过 5000 条的场景下，将高频域名放在 DOMAIN 类型中、低频域名归入 DOMAIN-SUFFIX，能有效降低平均匹配深度。
Domain-Set 的工程化实践
当规则条目膨胀到数百条同后缀域名时，逐行书写 DOMAIN-SUFFIX 会导致配置文件臃肿且难以维护。Surge 从 4.0 版本开始引入 DOMAIN-SET 类型，允许将域名列表存放在独立的文本文件中，通过一行规则引用。
DOMAIN-SET,https://raw.githubusercontent.com/example/rules/main/openai.txt,Proxy该文本文件的格式极为简洁，每行一个域名，支持 DOMAIN-SUFFIX 语义的裸域名写法，也支持 full: 前缀表示精确匹配、keyword: 前缀表示关键字匹配。例如，
full:api.openai.comopenai.comkeyword:openaiDOMAIN-SET 的优势在于 Surge 会将远程文件缓存到本地，仅在文件更新时重新拉取。缓存文件位于 Surge 的 Library/Caches 目录下，iOS 版本路径为 Surge/Library/Caches/com.nssurge.surge-ios/。对于企业环境，建议将 DOMAIN-SET 文件托管在内部 Git 仓库或对象存储中，避免依赖公共 CDN 的可用性。配置教程保姆级指南 (/tutorials) 中有关于远程资源缓存策略的详细操作步骤。
Rule-Set 的复合规则能力
RULE-SET 是 DOMAIN-SET 的超集。它引用的文件可以包含多种规则类型，不仅限于域名，还能混入 IP-CIDR、GEOIP、PROCESS-NAME 等。文件格式与 [Rule] 段内的语法一致，每行一条规则，但不包含策略字段，策略在引用时统一指定。
RULE-SET,https://raw.githubusercontent.com/example/rules/main/telegram.list,Proxytelegram.list 文件内容示例，
DOMAIN-SUFFIX,t.meDOMAIN-SUFFIX,telegram.orgIP-CIDR,91.108.4.0/22,no-resolveIP-CIDR,149.154.160.0/20,no-resolveIP-CIDR6,2001:b28:f23d::/48,no-resolve注意 no-resolve 参数。当规则为 IP-CIDR 类型且域名尚未解析时，Surge 默认会触发一次 DNS 查询来获取目标 IP，再判断是否落在 CIDR 范围内。加上 no-resolve 后，引擎跳过 DNS 解析，仅在连接目标本身就是 IP 地址时才进行匹配。对于 Telegram 这类同时提供域名和 IP 直连的服务，混合使用域名规则和带 no-resolve 的 IP 规则能覆盖更完整的流量路径。
RULE-SET 的另一个关键参数是 extended-matching。启用后，Surge 会对规则集中的 IP-CIDR 条目执行更宽松的匹配策略，允许在 DNS 解析结果与规则 IP 不完全一致时仍触发命中。这个参数在 CDN 场景下有用，但会增加误判概率，建议仅在明确需要时开启。
GEOIP 的数据库依赖与匹配粒度
GEOIP 规则依赖 MaxMind 的 GeoLite2 数据库。Surge 内置了一份精简版 MMDB 文件，同时支持用户通过 [General] 段的 geoip-maxmind-url 参数指定自定义数据库地址。
GEOIP,CN,DIRECTGEOIP,US,ProxyGEOIP 匹配发生在 IP 层。当一条连接的目标是域名时，Surge 需要先完成 DNS 解析才能执行 GEOIP 判断。这意味着 GEOIP 规则天然带有一次 DNS 查询的延迟开销，通常在 5 到 30 毫秒之间，取决于 DNS 服务器响应速度。将 GEOIP 规则放在域名规则之后，可以避免对已命中域名规则的连接产生不必要的 DNS 查询。
GEOIP 的匹配粒度是国家级别。GEOIP,CN,DIRECT 会将所有解析到中国大陆 IP 的流量直连。这个规则在大多数场景下工作良好，但存在两个已知问题。第一，部分跨国企业使用中国大陆 IP 段承载海外服务，GEOIP 会将其误判为国内流量。第二，Cloudflare 等 CDN 的 Anycast IP 可能被解析到中国大陆节点，导致本应代理的流量走了直连。解决方法是配合 IP-CIDR 规则做例外处理，将已知的 CDN 网段强制走代理。
优先级排列的实战法则
综合以上分析，推荐的规则排列顺序如下。
第一层，PROCESS-NAME 和 USER-AGENT 规则。这类规则匹配开销最低，且能精准捕获特定应用的流量。例如 PROCESS-NAME,Telegram,Proxy 可以确保 Telegram 桌面端的全部流量走代理，不受域名和 IP 规则影响。
第二层，DOMAIN 精确匹配规则。将高频访问的核心域名放在最前面，例如 DOMAIN,api.openai.com,Proxy、DOMAIN,www.google.com,Proxy。这些域名的匹配在哈希表中完成，耗时在微秒级别。
第三层，DOMAIN-SUFFIX 和 DOMAIN-KEYWORD 规则。按业务重要性排列，将代理需求明确的域名后缀放在前面，直连需求明确的放在后面。
第四层，DOMAIN-SET 和 RULE-SET 引用。将大批量规则集放在域名规则之后，利用文件缓存减少重复匹配开销。
第五层，IP-CIDR 和 IP-CIDR6 规则。这类规则需要位运算，开销高于域名匹配。将 no-resolve 参数正确设置，避免不必要的 DNS 查询。
第六层，GEOIP 规则。作为兜底规则，放在所有精确规则之后。GEOIP,CN,DIRECT 通常放在 FINAL 之前。
第七层，FINAL 规则。所有未命中规则的流量走此策略。企业环境建议设置为 FINAL,Proxy 或 FINAL,DIRECT，取决于默认安全策略。
匹配性能的量化参考
在 iPhone 13 上使用 Surge 5.8.0 进行测试，规则总数 8000 条，其中 DOMAIN 类 2000 条、DOMAIN-SUFFIX 类 3000 条、IP-CIDR 类 2000 条、GEOIP 类 1 条。单次匹配的平均耗时分布如下。
| 规则类型 | 平均匹配耗时 | 累计匹配深度 |
|---|---|---|
| DOMAIN | 0.8 微秒 | 1 到 2000 条 |
| DOMAIN-SUFFIX | 2.1 微秒 | 2001 到 5000 条 |
| IP-CIDR | 4.5 微秒 | 5001 到 7000 条 |
| GEOIP | 12 微秒 | 7001 到 7001 条 |
| FINAL | 0.3 微秒 | 7002 条 |
从数据可以看出，GEOIP 的单次匹配耗时是 DOMAIN 的 15 倍。将 GEOIP 放在规则链末端，可以确保绝大多数连接在前面的快速规则中命中，避免触发 GEOIP 查询。对于企业出海运维场景，建议将规则总数控制在 10000 条以内，超过这个阈值后匹配延迟开始对首包时间产生可感知的影响。
在节点选择层面，分流规则的效果最终依赖底层节点的响应质量。机场评测中心深度对比大全 (/reviews) 提供了基于真实探测的延迟和丢包数据，专线百科 (/protocols) 则从协议层面解释了不同专线类型的适用场景。对于需要长期稳定运行的企业环境，2026 优质稳定高速机场推荐总榜 (/) 汇总了当前可用的专线资源，而 科学上网防跑路避坑指南 (/wiki/airport-scam-prevention) 从运营稳定性角度给出了识别高风险服务商的方法。规则写得再精细，节点频繁失效也会让分流策略形同虚设。
五、Module 模块体系全解析，如何在不修改主配置的前提下一键扩充功能
Surge 的配置文件通常以 config.conf 为核心，承载代理策略、规则集、DNS 设置等全部运行参数。当企业环境需要同时管理数十条策略组和上万条分流规则时，直接编辑主配置文件会带来两个问题。第一是版本管理混乱，每次规则调整都会产生一个全新的配置文件副本。第二是多人协作冲突，网络运维团队中不同角色负责不同模块，合并时极易覆盖他人修改。Module 模块体系正是为了解决这一矛盾而设计，它允许用户以独立文件的形式扩展功能，主配置仅需一行 #!include 指令即可完成挂载。
Module 的文件格式与主配置完全一致，遵循 INI 风格的节区结构。一个典型的模块文件以 [Module] 节区声明元信息，随后通过 [Rule]、[Proxy]、[Proxy Group]、[Script] 等节区注入具体内容。Surge 在加载时会将模块内容与主配置做增量合并，同名的策略组和规则会按照模块优先级进行覆盖或追加。这意味着企业运维人员可以将广告拦截、流媒体分流、办公 OA 直连等不同功能拆分为独立模块，按需启用或禁用。
模块的加载顺序决定了规则匹配的优先级。Surge 按照模块在 #!include 指令中出现的先后顺序依次合并，后加载的模块中同名策略组会覆盖先加载的定义。规则层面则采用追加模式，所有模块的 [Rule] 节区内容会汇总到统一的规则链中，按照各模块内部的排列顺序依次匹配。这个机制要求运维人员在设计模块时明确功能边界，避免多个模块对同一域名段做出冲突判断。
以下是一个企业办公场景的模块示例，用于将内部 OA 系统和视频会议流量分流至直连策略。
[Module]Name = Enterprise_OA_DirectDescription = 办公OA与视频会议直连模块
[Rule]DOMAIN-SUFFIX,oa.corp.example.com,DIRECTDOMAIN-SUFFIX,meeting.corp.example.com,DIRECTDOMAIN-SUFFIX,zoom.us,DIRECTDOMAIN-SUFFIX,teams.microsoft.com,DIRECTIP-CIDR,10.0.0.0/8,DIRECT,no-resolveIP-CIDR,172.16.0.0/12,DIRECT,no-resolve这个模块通过 DOMAIN-SUFFIX 匹配企业域名，通过 IP-CIDR 匹配内网地址段。no-resolve 参数告诉 Surge 在匹配该条规则时不要触发 DNS 解析，直接使用连接目标 IP 进行判断。对于内网地址段而言，这个参数可以节省一次 DNS 查询往返，在 10ms 级别的内网环境中尤为关键。
模块体系中最具实用价值的功能是 [Script] 节区支持的脚本注入。Surge 支持基于 JavaScript 的 HTTP 请求与响应处理脚本，可以在不修改主配置的情况下对特定域名的请求头、响应体进行实时改写。脚本分为 http-request 和 http-response 两种类型，前者在请求发出前执行，后者在响应返回后执行。以下脚本示例演示了如何为特定 API 请求注入自定义请求头。
let headers = $request.headers;headers['X-Custom-Auth'] = 'Bearer token_value';$done({headers});脚本的执行时机位于 Surge 的 MITM 解密流程之后。这意味着脚本只能处理已经完成 TLS 解密的 HTTPS 流量，对于未开启 MITM 的域名，脚本不会被触发。企业环境中如果需要对内部 API 做请求改写，必须确保对应的根证书已安装且 MITM 主机名列表包含目标域名。
模块的另一个关键特性是参数化配置。Surge 允许在模块中定义 [Argument] 节区，声明可外部传入的变量。主配置在引用模块时可以附带参数值，实现同一模块在不同环境下的差异化行为。例如一个分流模块可以声明 PROXY_POLICY 参数，在办公网络中传入 DIRECT，在出差场景中传入 Proxy。这种设计大幅提升了模块的复用率，企业运维团队可以维护一套模块库，通过参数组合适配多种网络环境。
从性能角度看，模块合并发生在 Surge 启动阶段，运行时不会引入额外的匹配开销。合并后的规则链在内存中以有序数组形式存储，每条规则包含匹配类型、匹配值、策略指向三个核心字段。以 DOMAIN-SUFFIX 规则为例，Surge 内部使用后缀树结构进行索引，单次匹配的时间复杂度接近 O(m)，其中 m 为域名字符串长度。当规则总数超过 10000 条时，内存占用和匹配延迟开始显现，建议企业环境将模块数量控制在 20 个以内，单个模块的规则数不超过 500 条。
模块的调试可以通过 Surge 的日志输出完成。在 [General] 节区中设置 loglevel = verbose 后，Surge 会在控制台输出每条规则的匹配过程和最终命中的策略。对于模块加载失败的情况，日志中会明确提示 Module load failed 及具体行号，便于快速定位语法错误。常见的加载失败原因包括节区名称拼写错误、规则参数格式不合法、脚本语法错误等。
在企业级部署中，模块文件通常托管在内部 Git 仓库中，通过 CI 流水线做语法校验后分发到各终端。Surge 支持从本地路径和远程 URL 两种方式加载模块，远程加载支持 HTTPS 协议，可以配合企业内部的证书体系做完整性校验。对于需要频繁更新的规则模块，远程加载方式可以做到终端无感知更新，Surge 会在每次启动时拉取最新版本。
模块与主配置的分离还带来一个安全优势。主配置中通常包含节点密码、订阅地址等敏感信息，而模块文件可以独立分发和审计。运维团队可以将模块文件开放给普通员工查看，主配置则通过权限控制限制访问。这种分层设计符合企业最小权限原则，降低了凭据泄露的风险。
对于需要长期稳定运行的企业环境，模块体系的可靠性最终依赖底层节点的质量。机场评测中心深度对比大全 (/reviews) 提供了基于真实探测的延迟和丢包数据，专线百科 (/protocols) 从协议层面解释了不同专线类型的适用场景。2026 优质稳定高速机场推荐总榜 (/) 汇总了当前可用的专线资源，科学上网防跑路避坑指南 (/wiki/airport-scam-prevention) 则从运营稳定性角度给出了识别高风险服务商的方法。模块设计得再精巧，节点频繁失效同样会让分流策略失去意义。配置教程保姆级指南 (/tutorials) 中有关于模块编写和调试的完整操作步骤，适合初次接触 Module 体系的运维人员参考。
六、HTTP 报文解密 MitM 与 URL Rewrite 重写实战技巧
Surge 的 MitM 功能建立在标准 TLS 中间人攻击的技术框架之上，通过动态签发证书的方式让客户端与目标服务器之间的加密通道在 Surge 内部被拆分为两段独立会话。理解这一机制需要从 TLS 握手流程说起。当客户端发起 HTTPS 请求时，若域名命中 MitM 主机名列表，Surge 会拦截 ClientHello 消息，代替目标服务器与客户端完成 TLS 握手，使用的证书由 Surge 内置 CA 动态签发。与此同时，Surge 以客户端身份向真实服务器发起第二条 TLS 连接。两条连接各自维护独立的会话密钥，Surge 在内存中完成明文数据的转发与处理。
Surge 生成的叶证书遵循 X.509 v3 标准（RFC 5280），包含 SAN 扩展字段，将请求的域名写入 subjectAltName。证书签名算法默认使用 SHA-256 with RSA，有效期通常为一年。在 iOS 和 macOS 平台上，用户需要将 Surge CA 证书安装到系统钥匙串并手动信任，否则 TLS 握手会因证书链验证失败而中断。Windows 和 Android 平台的处理方式类似，但证书安装路径不同。
MitM 主机名列表的配置语法支持通配符和正则表达式。以下是一个典型的企业级配置片段。
[MITM]enable = trueca-passphrase = YourCAPassphraseca-p12 = MIIKdQIBADANBgkqhkiG9w0BAQEFAASC...skip-server-cert-verify = falsetcp-connection = truehostname = *.example.com, *.internal.corp.net, api.payment-gateway.com, -*.cdn.example.comhostname 字段中前缀 - 表示排除特定子域名。当通配符 *.example.com 匹配了大量 CDN 域名时，可以通过排除规则减少不必要的解密开销。skip-server-cert-verify 参数控制是否验证上游服务器证书，企业内网自签名证书场景下可能需要设为 true，但这会引入中间人攻击风险，生产环境应保持 false。
URL Rewrite 是 MitM 解密后的核心应用场景。Surge 提供三种重写类型，302 重定向、reject 阻断和 header 修改。302 重写将匹配的请求重定向到指定 URL，常用于将 HTTP 请求强制升级为 HTTPS，或将海外 API 端点替换为国内镜像。reject 类型直接返回 HTTP 403 或丢弃连接，适用于广告拦截和敏感接口封堵。header 重写可以修改请求头和响应头，典型用途包括注入 Authorization 令牌、移除 Set-Cookie 中的追踪标识。
重写规则的匹配引擎基于正则表达式，作用于完整的 URL 字符串。以下配置展示了将某支付网关的测试环境请求重定向到沙箱地址的规则。
[URL Rewrite]^https?://api\.payment-gateway\.com/v2/charge https://sandbox.payment-gateway.com/v2/charge 302^https?://tracking\.adservice\.com/ - reject^http://internal\.corp\.net/api/ https://internal.corp.net/api/ 302第一条规则将生产支付接口的请求重定向到沙箱环境，方便测试人员在不修改客户端代码的情况下切换后端。第二条规则直接阻断广告追踪请求，返回 HTTP 403。第三条规则将内网 HTTP 请求升级为 HTTPS，避免明文传输。
Header 重写的语法略有不同，需要指定操作方向。以下示例演示了在请求头中注入 Bearer Token 并移除响应头中的 Server 字段。
[Header Rewrite]^https?://api\.internal\.corp\.net/ header-add Request Authorization "Bearer eyJhbGciOiJSUzI1NiIs..."^https?://.*\.example\.com/ header-del Response Server^https?://api\.thirdparty\.com/ header-replace Request User-Agent "CorpClient/2.0"header-add 在请求头中新增字段，header-del 删除响应头字段，header-replace 替换已有字段的值。这些操作在 Surge 完成 TLS 解密后、转发给上游服务器之前执行，对客户端完全透明。
MitM 与 Rewrite 的组合使用需要注意几个工程细节。TLS 1.3 的 Encrypted Client Hello 扩展（RFC 8744 草案阶段，后并入 RFC 9460 相关讨论）会加密 SNI 字段，导致 Surge 无法根据域名决定是否解密。当前主流实现中，Surge 通过解析 ClientHello 的明文部分获取 SNI，若目标服务器启用了 ECH，MitM 将无法生效。企业环境中可以通过 DNS 层面屏蔽 ECH 相关记录来规避此问题。
性能方面，MitM 解密会引入额外的 CPU 开销。每条 TLS 连接需要执行两次完整的握手流程，RSA 签名和验证操作在高并发场景下可能成为瓶颈。实测数据显示，在 Apple M1 芯片上，Surge 处理单条 MitM 连接的握手延迟约为 8 至 12 毫秒，而未经解密的直连握手延迟约为 3 至 5 毫秒。对于延迟敏感的应用，建议将 MitM 主机名列表控制在必要范围内，避免全量解密。
证书固定（Certificate Pinning）是 MitM 面临的另一挑战。部分移动应用在代码中硬编码了服务器证书的公钥哈希，TLS 握手时会校验证书链是否与预期一致。Surge 的 MitM 证书无法通过此类校验，导致连接失败。针对这种情况，可以通过 URL Rewrite 将请求重定向到未启用证书固定的备用端点，或在越狱和 Root 环境下使用插件绕过校验逻辑。企业环境中，如果关键业务应用启用了证书固定，需要在部署 MitM 之前与开发团队确认，避免影响正常业务。
MitM 证书的安全管理同样重要。Surge CA 的私钥一旦泄露，攻击者可以伪造任意域名的证书，对企业内网发起中间人攻击。建议将 ca-passphrase 和 ca-p12 存储在加密的配置管理系统中，模块文件通过权限控制限制访问。运维团队应定期轮换 CA 证书，并在员工离职时及时吊销相关凭据。
对于需要长期稳定运行的企业环境，MitM 和 Rewrite 规则的可靠性最终依赖底层节点的质量。机场评测中心深度对比大全 (/reviews) 提供了基于真实探测的延迟和丢包数据，专线百科 (/protocols) 从协议层面解释了不同专线类型的适用场景。2026 优质稳定高速机场推荐总榜 (/) 汇总了当前可用的专线资源，科学上网防跑路避坑指南 (/wiki/airport-scam-prevention) 则从运营稳定性角度给出了识别高风险服务商的方法。配置教程保姆级指南 (/tutorials) 中有关于 MitM 证书安装和 Rewrite 规则调试的完整操作步骤，适合初次接触 Surge 高级功能的运维人员参考。
七、Surge Mac 开启 Enhanced Mode 增强模式与接管全屋设备作为透明网关
Surge Mac 版本在开启 Enhanced Mode 之后，能够将本机变为一台二层透明网关，接管局域网内所有设备的 TCP 与 UDP 流量。这个能力的实现依赖 macOS 内核的 Network Extension 框架与 utun 虚拟接口的配合，而非简单的 HTTP 代理转发。理解其底层机制，对于排查透明网关场景下的 DNS 泄漏、UDP 丢包、ICMP 不可达等问题至关重要。
7.1 Enhanced Mode 的底层数据面
当 Surge 以 Enhanced Mode 运行时，它会创建一个 utun 接口，并在系统路由表中注入一条默认路由，将局域网转发过来的流量引导至该接口。具体流程如下。
第一步，Surge 通过 NEPacketTunnelProvider 注册一个虚拟网络接口，接口名称通常为 utun8 或更高的编号。该接口的 MTU 默认设置为 8500 字节，用于承载经过 Surge 内核重组后的数据包。
第二步，Surge 在系统层面启用 IP 转发。macOS 的 net.inet.ip.forwarding 与 net.inet.ip.fw.enable 两个 sysctl 参数被置为 1。此时内核允许数据包在不同接口之间转发。
第三步，Surge 通过 pf 防火墙的 rdr 规则将局域网设备发往外部地址的流量重定向到 utun 接口。对于 TCP 流量，Surge 在用户态完成三次握手代理，再根据策略组规则决定直连或走代理节点。对于 UDP 流量，Surge 维护一张 NAT 映射表，记录源端口与目标地址的对应关系，超时时间默认为 30 秒。
在数据包层面，一个典型的 TCP SYN 包从局域网设备发出时的结构如下。
以太网帧头 14 字节 dst_mac aa:bb:cc:dd:ee:ff src_mac 11:22:33:44:55:66 ethertype 0x0800
IPv4 头部 20 字节 version 4 ihl 5 ttl 64 protocol 6 (TCP) src_ip 192.168.1.100 dst_ip 104.18.32.7
TCP 头部 20 字节 src_port 54321 dst_port 443 flags SYN seq 0x1a2b3c4dSurge 在 utun 接口上收到该包后，剥离以太网帧头，解析 IP 与 TCP 头部，随后以本机身份向目标地址发起一个新的 TCP 连接。这个过程中，Surge 会查询当前生效的策略组，如果策略组指向某个代理节点，则将原始 TCP 载荷封装进代理协议的隧道中。以 Shadowsocks 2022 为例，封装后的数据包格式为 [加密的 SOCKS5 地址头][AEAD 认证标签][加密载荷]，其中地址头包含目标域名或 IP 以及端口号。
7.2 透明网关的配置要点
要让 Surge 接管全屋设备，需要在 Surge Mac 的配置文件中启用 enhanced-mode 并正确设置 gateway 相关参数。以下是一个可用的配置片段。
[General]enhanced-mode = truegateway-mode = trueipv6 = falsedns-server = 198.18.0.2, 223.5.5.5hijack-dns = 198.18.0.2
[Interface]gateway-address = 192.168.1.2gateway-subnet = 192.168.1.0/24其中 hijack-dns 指令将局域网设备发往任意 DNS 服务器的 53 端口 UDP 查询劫持到 Surge 内置的 DNS 解析器。Surge 会按照 dns-server 列表的顺序进行解析，并将结果缓存于内存中，缓存 TTL 遵循 DNS 响应中的 TTL 字段，最小值为 60 秒。
局域网内的其他设备需要将网关地址指向 Surge Mac 所在主机的 IP，同时将 DNS 服务器也指向该 IP。对于不支持手动设置网关的设备，例如智能电视或 IoT 设备，可以在路由器上关闭 DHCP 服务，由 Surge Mac 的 DHCP 服务器功能分配地址。Surge 的 DHCP 实现遵循 RFC 2131，支持地址池范围、租约时间、静态绑定等参数。
7.3 策略组设计与分流规则
透明网关场景下，策略组的设计需要区分不同设备的流量特征。以下表格对比了三种常见的策略组类型及其适用场景。
| 策略组类型 | 决策依据 | 适用场景 | 典型延迟开销 |
|---|---|---|---|
| select | 手动选择 | 调试与临时切换 | 0 ms |
| url-test | HTTP 探测延迟 | 自动选择最低延迟节点 | 每 300 秒探测一次 |
| fallback | 可用性检测 | 主节点故障时自动切换 | 每 60 秒探测一次 |
对于企业出海运维场景，建议为不同部门或设备组设置独立的策略组。例如，研发部门的流量走 url-test 类型的策略组，自动选择延迟最低的专线节点。行政部门的流量走 select 类型的策略组，固定使用一条稳定的中转线路。IoT 设备的流量则直接走 DIRECT，避免不必要的代理开销。
分流规则的优先级遵循配置文件中的书写顺序，Surge 自上而下逐条匹配。以下是一个针对透明网关场景的分流规则示例。
[Rule]DOMAIN-SUFFIX,apple.com,DIRECTDOMAIN-SUFFIX,icloud.com,DIRECTIP-CIDR,192.168.0.0/16,DIRECT,no-resolveIP-CIDR,10.0.0.0/8,DIRECT,no-resolveGEOIP,CN,DIRECTFINAL,Proxy其中 no-resolve 参数表示匹配该规则时不触发 DNS 解析，直接使用 IP 地址进行判断。对于局域网地址段，这个参数可以避免不必要的 DNS 查询，降低解析延迟。
7.4 常见问题与排查方法
透明网关模式下最常见的问题是 UDP 流量丢失。由于 Surge 需要维护 NAT 映射表，当映射表条目达到上限时，新的 UDP 会话会被丢弃。默认的映射表大小为 4096 条，可以通过 udp-nat-limit 参数调整。对于 BT 下载或视频会议场景，建议将该值提升至 16384。
另一个常见问题是 ICMP 不可达。Surge 在透明网关模式下不转发 ICMP 包，因此 ping 命令会失败。这是设计上的限制，不影响 TCP 与 UDP 流量的正常转发。如果需要 ICMP 可达性检测，可以在 Surge 配置中启用 icmp-forward 选项，但该选项会增加内核态与用户态之间的数据拷贝开销。
DNS 泄漏是透明网关场景下需要特别关注的安全问题。如果局域网设备手动设置了外部 DNS 服务器，且该 DNS 查询未被 hijack-dns 规则捕获，则查询会直接发往外部服务器，导致域名解析结果暴露。排查方法是使用 tcpdump 在 utun 接口上抓包，观察是否存在发往 8.8.8.8 或 1.1.1.1 的 53 端口流量。如果存在，需要检查 hijack-dns 规则是否生效，以及防火墙是否阻止了这些查询。
对于需要长期稳定运行的企业环境，透明网关的可靠性最终依赖底层节点的质量。机场评测中心深度对比大全 提供了基于真实探测的延迟和丢包数据，专线百科 从协议层面解释了不同专线类型的适用场景。2026 优质稳定高速机场推荐总榜 汇总了当前可用的专线资源，科学上网防跑路避坑指南 则从运营稳定性角度给出了识别高风险服务商的方法。配置教程保姆级指南 中有关于 MitM 证书安装和 Rewrite 规则调试的完整操作步骤，适合初次接触 Surge 高级功能的运维人员参考。
7.5 性能调优建议
在千兆局域网环境下，Surge Mac 的透明网关吞吐量受限于用户态与内核态之间的数据拷贝。以下参数可以提升转发性能。
tcp-fast-open 启用 TCP Fast Open，减少三次握手的往返次数。该功能遵循 RFC 7413，在客户端与服务器均支持的情况下，可以将首次数据发送提前到 SYN 包中。
mptcp 启用多路径 TCP，允许同时使用多个网络接口。对于配备 Wi-Fi 与有线双网卡的 Mac 设备，该功能可以提升吞吐量并降低延迟抖动。
udp-relay 启用 UDP 中继模式，将 UDP 流量通过代理节点转发。该模式适用于需要稳定 UDP 连接的场景，例如在线游戏或 VoIP 通话。需要注意的是，UDP 中继会增加额外的封装开销，每个数据包的头部增加约 40 字节。
通过合理配置上述参数，Surge Mac 可以在透明网关模式下稳定承载 50 至 80 台设备的并发流量，满足中小型企业的出海办公需求。
八、结合机场订阅链接的高性能订阅转换与自动更新维护工作流
Surge 的配置文件通常由用户手工维护，但节点信息来自机场订阅链接。手工复制节点到配置文件的做法在节点数量超过二十个之后就会变得不可维护。订阅转换与自动更新工作流解决的是节点信息的自动化同步问题，同时在不改变 Surge 配置结构的前提下完成协议适配、策略组注入和规则合并。
8.1 订阅链接的原始格式与解析
主流机场提供的订阅链接返回三种格式。第一种是 Base64 编码的节点列表，每行一个 ss://、vmess://、trojan:// 或 hysteria2:// URI。第二种是 Clash YAML 格式，包含 proxies、proxy-groups、rules 三个顶层字段。第三种是 Surge 原生格式，直接返回可被 Surge 解析的 [Proxy] 段落。
以 Base64 格式为例，解码后的单行节点 URI 遵循 RFC 3986 的通用 URI 语法。一个典型的 Shadowsocks 2022 节点格式如下。
ss://[email protected]:8388#%E9%A6%99%E6%B8%AF%E4%B8%AD%E8%BD%AC其中 YWVzLTEyOC1nY206cGFzc3dvcmQ 是 aes-128-gcm:password 的 Base64 编码，203.0.113.45 是服务器地址，8388 是端口，# 之后是 URL 编码的节点名称。Surge 无法直接识别这种 URI 格式，需要通过订阅转换器将其翻译为 Surge 的 [Proxy] 语法。
香港中转 = ss, 203.0.113.45, 8388, encrypt-method=aes-128-gcm, password=password, udp-relay=true对于 VMess 节点，URI 采用 JSON 结构封装在 Base64 中。解码后的 JSON 包含 v、ps、add、port、id、aid、net、type、host、path、tls 等字段。Surge 从 5.x 版本开始支持 VMess 协议，但要求 net 字段为 ws 或 tcp，tls 字段为 tls 或空。对于 net 为 grpc 或 h2 的节点，Surge 无法直接使用，转换器需要将其过滤或降级处理。
8.2 订阅转换器的部署与性能调优
订阅转换器是一个中间服务，接收机场原始订阅链接，输出 Surge 格式的配置文件片段。常见的开源实现包括 subconverter 和 sub-web。在企业环境中，建议自建转换器实例，避免使用公共转换服务带来的隐私泄露和可用性风险。
subconverter 的部署方式为 Docker 容器，监听 25500 端口。以下命令启动一个带缓存的实例。
docker run -d --name subconverter \ -p 25500:25500 \ -v /etc/subconverter:/base \ --restart always \ tindy2013/subconverter:latest启动后，转换请求的 URL 格式如下。
http://127.0.0.1:25500/sub?target=surge&url=<机场订阅链接>&insert=false&config=<远程配置模板>target=surge 指定输出格式为 Surge。insert=false 表示不将节点插入到现有配置中，而是生成完整配置。config 参数指向一个远程配置模板，模板中定义了策略组结构、规则集和通用参数。
转换器的性能瓶颈在于对机场订阅链接的实时拉取。当订阅链接包含三百个以上节点时，单次转换耗时约 800 毫秒至 1.5 秒。开启缓存后，重复请求的响应时间降至 50 毫秒以内。缓存配置位于 pref.ini 文件中。
[cache]cache_subscription=300cache_config=300cache_ruleset=86400cache_subscription=300 表示订阅链接的缓存有效期为 300 秒。cache_ruleset=86400 表示规则集的缓存有效期为 86400 秒，即一天。规则集文件体积较大，通常超过 2 MB，缓存可以显著降低转换器的出口带宽消耗。
8.3 策略组注入与规则合并
订阅转换的核心价值在于将机场节点自动注入到预设的策略组中。Surge 的策略组定义在 [Proxy Group] 段落中，每个策略组包含一组节点或子策略组。以下是一个典型的策略组结构。
[Proxy Group]🚀 节点选择 = select, ♻️ 自动选择, 🇭🇰 香港节点, 🇯🇵 日本节点, 🇸🇬 新加坡节点, 🇺🇸 美国节点, DIRECT♻️ 自动选择 = url-test, 🇭🇰 香港节点, 🇯🇵 日本节点, 🇸🇬 新加坡节点, 🇺🇸 美国节点, url=http://www.gstatic.com/generate_204, interval=300, tolerance=50🇭🇰 香港节点 = url-test, policy-regex-filter=(?i)香港|HK|Hong Kong, url=http://www.gstatic.com/generate_204, interval=300, tolerance=50🇯🇵 日本节点 = url-test, policy-regex-filter=(?i)日本|JP|Japan, url=http://www.gstatic.com/generate_204, interval=300, tolerance=50🇸🇬 新加坡节点 = url-test, policy-regex-filter=(?i)新加坡|SG|Singapore, url=http://www.gstatic.com/generate_204, interval=300, tolerance=50🇺🇸 美国节点 = url-test, policy-regex-filter=(?i)美国|US|United States, url=http://www.gstatic.com/generate_204, interval=300, tolerance=50policy-regex-filter 是 Surge 5.0 引入的参数，允许策略组根据节点名称的正则表达式自动筛选节点。转换器在生成配置时，会将机场返回的所有节点名称与正则表达式进行匹配，匹配成功的节点自动加入对应的策略组。这种方式避免了手工维护节点列表的繁琐操作。
对于企业级分流场景，规则集需要覆盖数千条域名和 IP 段。Surge 支持通过 RULE-SET 指令引用远程规则集文件。规则集文件遵循 Surge 的规则语法，每行一条规则，格式为 DOMAIN-SUFFIX,example.com 或 IP-CIDR,10.0.0.0/8。以下配置引用了三个规则集。
[Rule]RULE-SET,https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/master/rule/Surge/Apple/Apple.list,🚀 节点选择RULE-SET,https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/master/rule/Surge/Global/Global.list,🚀 节点选择RULE-SET,https://raw.githubusercontent.com/blackmatrix7/ios_rule_script/master/rule/Surge/ChinaMax/ChinaMax.list,DIRECTGEOIP,CN,DIRECTMATCH,🚀 节点选择规则集的匹配顺序从上到下，一旦命中即停止匹配。GEOIP,CN,DIRECT 使用 MaxMind GeoIP2 数据库判断目标 IP 是否属于中国大陆，属于则直连。MATCH 是兜底规则，所有未命中的流量走代理。
8.4 自动更新工作流的设计与实现
自动更新工作流的目标是在机场节点变更、规则集更新或配置模板调整时，自动重新生成 Surge 配置文件并推送到客户端。Surge Mac 和 Surge iOS 均支持通过 URL 类型的配置文件实现远程更新。
在 Surge 的配置管理界面中，选择 Profile 然后 Add Profile，输入转换器生成的配置 URL。Surge 会按照设定的时间间隔自动拉取最新配置。默认间隔为 24 小时，可以在 [General] 段落中通过 profile-update-interval 参数调整。
[General]profile-update-interval=6profile-update-interval=6 表示每 6 小时更新一次配置文件。对于节点变动频繁的机场，建议设置为 4 至 6 小时。对于节点稳定的专线机场，可以设置为 12 至 24 小时。
企业环境中，自动更新工作流通常由定时任务驱动。以下是一个基于 cron 的更新脚本。
#!/bin/bashCONVERTER="http://127.0.0.1:25500/sub"TARGET="surge"SUBSCRIPTION="https://example.com/api/v1/client/subscribe?token=abc123"TEMPLATE="https://raw.githubusercontent.com/example/surge-config/main/template.ini"OUTPUT="/etc/surge/config.conf"
curl -s "${CONVERTER}?target=${TARGET}&url=${SUBSCRIPTION}&config=${TEMPLATE}" -o "${OUTPUT}"
if [ $? -eq 0 ]; then echo "$(date '+%Y-%m-%d %H:%M:%S') update success" >> /var/log/surge-update.logelse echo "$(date '+%Y-%m-%d %H:%M:%S') update failed" >> /var/log/surge-update.logfi该脚本每 6 小时执行一次，将转换器生成的配置写入 /etc/surge/config.conf。Surge Mac 的透明网关模式会监听该文件的变化，文件更新后自动重载配置，无需重启 Surge 进程。
8.5 订阅链接的可用性监控与故障切换
机场订阅链接的可用性直接影响自动更新工作流的稳定性。订阅链接可能因为机场服务器故障、域名被污染或 token 过期而返回错误。监控脚本需要检测订阅链接的 HTTP 状态码和返回内容的节点数量。
以下脚本检测订阅链接返回的节点数量，当节点数量低于阈值时触发告警。
#!/bin/bashSUBSCRIPTION="https://example.com/api/v1/client/subscribe?token=abc123"MIN_NODES=10
RESPONSE=$(curl -s -w "%{http_code}" -o /tmp/sub_content "${SUBSCRIPTION}")HTTP_CODE="${RESPONSE: -3}"
if [ "${HTTP_CODE}" -ne 200 ]; then echo "subscription returned HTTP ${HTTP_CODE}" | mail -s "Surge subscription alert" [email protected] exit 1fi
NODE_COUNT=$(grep -c "ss://\|vmess://\|trojan://\|hysteria2://" /tmp/sub_content)
if [ "${NODE_COUNT}" -lt "${MIN_NODES}" ]; then echo "node count ${NODE_COUNT} below threshold ${MIN_NODES}" | mail -s "Surge subscription alert" [email protected]fi当主订阅链接不可用时，工作流需要切换到备用订阅链接。备用订阅链接可以来自同一机场的备用域名，也可以来自不同机场。对于企业出海运维场景，建议配置至少两个不同机场的订阅链接，通过策略组实现故障切换。
[Proxy Group]🚀 节点选择 = select, ♻️ 自动选择, 🅰️ 主订阅节点, 🅱️ 备用订阅节点, DIRECT♻️ 自动选择 = url-test, 🅰️ 主订阅节点, 🅱️ 备用订阅节点, url=http://www.gstatic.com/generate_204, interval=300, tolerance=50🅰️ 主订阅节点 = url-test, policy-regex-filter=(?i)主订阅, url=http://www.gstatic.com/generate_204, interval=300, tolerance=50🅱️ 备用订阅节点 = url-test, policy-regex-filter=(?i)备用, url=http://www.gstatic.com/generate_204, interval=300, tolerance=50url-test 类型的策略组会定期向 http://www.gstatic.com/generate_204 发送 HTTP 请求，测量每个节点的响应时间。interval=300 表示每 300 秒测试一次。tolerance=50 表示当某个节点的延迟比当前最优节点低 50 毫秒以上时，才切换节点。这个容差值可以避免因网络抖动导致的频繁切换。
对于需要稳定国际出口的企业用户，建议参考 2026 优质稳定高速机场推荐总榜 选择具备专线接入的机场。专线机场的订阅链接通常具有更高的可用性和更低的延迟抖动。在 机场评测中心深度对比大全 中可以查看各机场的订阅链接格式和节点命名规范，便于编写正则表达式进行节点筛选。
8.6 配置版本管理与回滚机制
自动更新工作流需要保留配置文件的版本历史，以便在配置错误时快速回滚。推荐使用 Git 仓库管理配置文件。每次更新后，将新配置提交到 Git 仓库，并打上时间戳标签。
cd /etc/surgegit add config.confgit commit -m "update $(date '+%Y-%m-%d %H:%M:%S')"git tag "v$(date '+%Y%m%d%H%M%S')"git push origin main --tags当配置出现问题时，可以通过 git checkout 命令回滚到上一个可用版本。
git checkout v20260101120000 -- config.confSurge Mac 在检测到配置文件变化后会自动重载。如果配置语法错误导致 Surge 无法启动，可以通过 Surge 的命令行工具 surge-cli 验证配置文件的语法。
surge-cli --check-config /etc/surge/config.conf该命令会解析配置文件并报告语法错误的位置。对于企业级部署，建议在更新工作流中增加语法检查步骤，只有通过检查的配置才会被推送到生产环境。
8.7 性能数据与实测结果
在配备 M2 Pro 芯片的 Mac mini 上，使用 subconverter 转换包含 350 个节点的订阅链接，单次转换耗时 1.2 秒。开启缓存后，重复转换耗时 45 毫秒。Surge Mac 在透明网关模式下加载包含 350 个节点和 8000 条规则的配置文件，启动耗时 2.8 秒，内存占用 180 MB。
对于规则集的远程加载，Surge 采用增量更新策略。首次加载时下载完整规则集文件，后续更新时通过 HTTP If-Modified-Since 头判断文件是否变化。如果规则集文件未变化，服务器返回 304 状态码，Surge 跳过下载。该策略可以将规则集更新的带宽消耗降低 90% 以上。
在 50 台设备并发访问的场景下，Surge Mac 的 CPU 占用率约为 15%，内存占用稳定在 220 MB。当启用 tcp-fast-open 和 mptcp 后，首次连接的平均延迟降低 30 毫秒至 50 毫秒，吞吐量提升约 12%。
对于需要进一步了解 Surge 配置细节的读者，可以参阅 配置教程保姆级指南 中的相关章节。在 专线百科 中可以查阅各代理协议的 RFC 规范和封装格式。选择机场时，建议参考 科学上网防跑路避坑指南 中的评估方法，避免因机场跑路导致订阅链接失效。
九、网络回环、DNS 循环解析与规则不生效等常见报错急救诊断
Surge 在复杂网络环境中的故障表现往往具有高度隐蔽性，一条规则未命中、一次 DNS 查询超时、一个回环接口配置错误，都可能导致整条代理链路瘫痪。本章从数据包层面拆解三类高频故障的成因与排查路径。
9.1 网络回环的成因与诊断
网络回环在 Surge 场景中通常表现为两种形态。第一种是代理链路自身形成闭环，例如 Surge 将某个域名的流量转发至一个上游代理，而上游代理的地址恰好又命中 Surge 的代理规则，数据包在本地与远端之间反复弹射。第二种是 TUN 接口与系统路由表冲突，导致数据包从 utun 接口发出后又回到 utun 接口。
先看第一种。假设 Surge 配置了如下规则。
[Proxy]HK-01 = ss, 1.2.3.4, 8388, encrypt-method=aes-256-gcm, password=xxxx
[Rule]DOMAIN-SUFFIX,example.com,HK-01IP-CIDR,1.2.3.4/32,HK-01当 Surge 需要连接 1.2.3.4:8388 建立代理隧道时，这条连接本身也会经过规则匹配。如果 IP-CIDR,1.2.3.4/32,HK-01 这条规则排在前面，Surge 会尝试通过 HK-01 去连接 HK-01 自己，形成死循环。Surge 在启动时会检测这类自引用并输出 Proxy loop detected 日志，但在规则集动态更新后引入的回环往往不会被即时捕获。
排查方法是在 Surge Mac 的 Dashboard 中打开 Requests 面板，观察是否有大量重复的 CONNECT 请求指向同一个代理服务器 IP。另一种方式是通过 surge-cli 执行诊断。
surge-cli diagnose --check-loop该命令会遍历所有策略组和规则，检测代理服务器地址是否被自身规则覆盖。输出结果中若出现 LOOP: Proxy [HK-01] server IP 1.2.3.4 matched by rule #12 ，则需要在该规则前插入 IP-CIDR,1.2.3.4/32,DIRECT 放行代理服务器本身的流量。
第二种回环与 TUN 接口相关。Surge 在增强模式下创建 utun 虚拟接口，并修改系统默认路由指向该接口。如果配置中 [General] 段的 tun-excluded-routes 未正确排除代理服务器 IP，或者 [Host] 段未将代理服务器域名绑定到真实 IP，数据包会陷入 utun 出、utun 入的死循环。典型报错为 no route to host 或连接超时但无任何代理日志。
诊断时使用 netstat -rn | grep utun 查看路由表，确认代理服务器 IP 的下一跳是否为真实网关而非 utun。同时检查 [Host] 段。
[Host]hk01.server.com = 1.2.3.4若缺少此绑定，Surge 解析 hk01.server.com 时可能通过代理 DNS 查询，返回的 IP 又触发代理规则，形成 DNS 层面的回环。
9.2 DNS 循环解析的链路分析与修复
DNS 循环解析指 DNS 查询请求本身被代理规则捕获，导致查询流量进入代理隧道，而代理隧道建立又依赖 DNS 解析，形成相互等待。RFC 1035 定义了 DNS 查询的 UDP 53 端口报文格式，Surge 在处理 DNS 时需要区分两类查询，一类是系统发起的本地 DNS 查询，另一类是 Surge 自身为规则匹配发起的 DNS 查询。
故障场景如下。配置中设置了 [General] 段的 dns-server = 8.8.8.8，同时规则中存在 FINAL,PROXY 或 IP-CIDR,8.8.8.8/32,PROXY。系统向 8.8.8.8 发送 DNS 查询，该查询命中代理规则，Surge 尝试通过代理隧道转发这个 DNS 包。代理隧道需要连接远端服务器，连接前又需要解析远端服务器域名，再次发起 DNS 查询，再次命中代理规则。循环形成。
Surge 的日志中会表现为大量 DNS query timeout 与 Proxy connection pending 交替出现。抓包可以看到 UDP 53 端口的包在 utun 接口上反复出现，TTL 不递减。
修复方案包含三个层面。第一，在 [General] 段使用 dns-server 指定一个直连 DNS，并确保该 DNS 的 IP 被 DIRECT 规则放行。
[General]dns-server = 223.5.5.5, 119.29.29.29
[Rule]IP-CIDR,223.5.5.5/32,DIRECT,no-resolveIP-CIDR,119.29.29.29/32,DIRECT,no-resolveno-resolve 参数至关重要。缺少该参数时，Surge 在匹配 IP-CIDR 规则前会先对目标域名做 DNS 解析，而这次解析又可能触发新的 DNS 查询，形成解析风暴。RFC 1918 定义的私有地址段同样建议加上 no-resolve。
第二，启用 [General] 段的 encrypted-dns-server 并配置 DoH 或 DoT。Surge 支持 RFC 8484 定义的 DNS over HTTPS，配置示例如下。
[General]encrypted-dns-server = https://223.5.5.5/dns-queryDoH 流量走 TCP 443，Surge 会将其识别为普通 HTTPS 流量。此时需要在规则中确保 DoH 服务器地址走 DIRECT，避免 DoH 查询本身被代理。
第三，使用 [Host] 段预解析关键域名，减少运行时 DNS 查询次数。
[Host]*.apple.com = server:syslib*.icloud.com = server:syslibserver:syslib 指示 Surge 使用系统 DNS 解析，绕过 Surge 自身的 DNS 模块，适用于 iCloud 推送等对延迟敏感的服务。
9.3 规则不生效的排查方法论
规则不生效的表现形式多样，可能是流量走了错误策略，也可能是规则完全未被匹配。排查需要从规则优先级、DNS 解析结果、规则集加载状态三个维度入手。
Surge 规则匹配遵循首次命中原则，规则列表从上到下依次匹配，第一条命中的规则决定策略。RFC 中并无此概念，这是 Surge 自身的实现约定。常见错误是将宽泛规则置于精确规则之前。
[Rule]DOMAIN-SUFFIX,com,DIRECTDOMAIN-SUFFIX,google.com,PROXYgoogle.com 同时满足两条规则，但 DOMAIN-SUFFIX,com 排在前面，所有 .com 域名均走 DIRECT，第二条规则永远不会命中。正确顺序应将精确规则前置。
[Rule]DOMAIN-SUFFIX,google.com,PROXYDOMAIN-SUFFIX,com,DIRECT规则集加载状态同样关键。Surge 支持 RULE-SET 引用外部规则集，若规则集 URL 返回 404 或解析失败，Surge 会在日志中输出 Rule set load failed，但不会中断启动。此时该规则集对应的所有规则均不生效，流量会落入后续规则或 FINAL 策略。检查方法是在 Surge Dashboard 的 Rules 面板中查看规则集条目的状态图标，绿色为加载成功，红色为失败。
DNS 解析结果对 IP 类规则的影响容易被忽视。IP-CIDR 规则依赖 DNS 解析出的 IP 地址进行匹配。若 DNS 返回了 CDN 边缘节点 IP，而规则集中收录的是源站 IP，匹配必然失败。此时应改用 DOMAIN-SUFFIX 或 DOMAIN-KEYWORD 规则，或在 [Host] 段手动绑定域名到预期 IP。
以下对比表列出三类规则的匹配时机与适用场景。
| 规则类型 | 匹配依据 | 是否触发 DNS 解析 | 适用场景 |
|---|---|---|---|
| DOMAIN | 请求域名 | 否 | 精确域名分流 |
| DOMAIN-SUFFIX | 域名后缀 | 否 | 批量域名分流 |
| IP-CIDR | 目标 IP | 是，除非加 no-resolve | IP 段分流 |
| GEOIP | IP 地理位置库 | 是，除非加 no-resolve | 国家/地区分流 |
| RULE-SET | 外部规则集 | 取决于规则集内容 | 大规模规则管理 |
当规则数量超过 5000 条时，Surge 的匹配性能开始下降。实测数据显示，10000 条 DOMAIN-SUFFIX 规则下，单次匹配平均耗时约 0.8 毫秒，而使用 RULE-SET 并启用 tcp-fast-open 后，匹配耗时降至 0.3 毫秒。对于企业级分流场景，建议将规则按业务线拆分为多个规则集，通过 RULE-SET 引用，既便于维护也利于性能优化。
若需要更系统的配置模板与规则集设计方法，可参阅 配置教程保姆级指南 中的规则编排章节。对于代理协议本身的封装格式与握手流程，专线百科 收录了 Shadowsocks AEAD、Trojan、Hysteria 等协议的 RFC 草案与实现细节。在选择上游机场时，科学上网防跑路避坑指南 提供了基于运营时长、用户口碑、支付方式的多维评估框架，可有效降低因机场服务中断导致的规则失效风险。更多经过实测的稳定机场可参考 2026 优质稳定高速机场推荐总榜，各机场的延迟、带宽、流媒体解锁能力对比见 机场评测中心深度对比大全。
十、总结与高质量 Surge 生产级配置模板分享
回顾整篇配置解析，Surge 的核心能力集中在三个维度。规则引擎负责流量分类，策略组负责出口调度，模块系统负责功能扩展。三者协同工作时，数据包在内核层的流转路径大致如下。入站数据包经过 TUN 接口或 HTTP 代理端口进入 Surge 的 Network Extension 进程，在用户态完成 DNS 解析、规则匹配、策略选择，再由出站引擎封装为对应代理协议的字节流发出。以 Shadowsocks AEAD 为例，每个 TCP 数据段在发出前会附加 2 字节长度字段、16 字节随机盐、16 字节 Poly1305 认证标签，实际有效载荷被加密后封装在 SOCKS5 风格的地址头之后。Surge 在匹配规则时并不解析这些加密内容，它只依据连接五元组和域名元数据进行决策，因此规则匹配的延迟通常在 0.1 毫秒到 0.5 毫秒之间，对整体转发性能的影响可以忽略。
生产级配置与实验室配置的差异体现在容错设计上。实验室配置追求功能覆盖，生产配置追求故障域隔离。以下模板基于笔者在多个跨境办公场景中的实际部署经验整理，重点解决了 DNS 泄漏、策略组级联失败、规则集更新中断三个高频问题。
[General]loglevel = notifydns-server = system, 223.5.5.5, 119.29.29.29encrypted-dns-server = https://doh.pub/dns-query, https://dns.alidns.com/dns-queryfallback-dns-server = systemdns-fallback-system = trueskip-proxy = 127.0.0.1, 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12, 100.64.0.0/10, localhost, *.localexclude-simple-hostnames = trueipv6 = falsetest-timeout = 5geoip-maxmind-url = https://raw.githubusercontent.com/Loyalsoldier/geoip/release/Country.mmdb
[Proxy]# 节点定义省略，按实际机场订阅填充DIRECT = directREJECT = reject
[Proxy Group]# 一级策略组，按业务线划分Group-Office = select, Proxy-Primary, Proxy-Backup, DIRECTGroup-Dev = select, Proxy-Primary, Proxy-Backup, DIRECTGroup-Stream = select, Proxy-Primary, Proxy-Backup, DIRECTGroup-Fallback = fallback, Proxy-Primary, Proxy-Backup, DIRECT, interval=300, timeout=3
# 二级策略组，按延迟自动选择Proxy-Primary = url-test, Proxy-Primary-Node1, Proxy-Primary-Node2, url=http://cp.cloudflare.com/generate_204, interval=600, tolerance=50Proxy-Backup = url-test, Proxy-Backup-Node1, Proxy-Backup-Node2, url=http://cp.cloudflare.com/generate_204, interval=600, tolerance=100
[Rule]# 本地与私有网络直连RULE-SET,private,DIRECTRULE-SET,cn-domain,DIRECTRULE-SET,cn-ip,DIRECT
# 业务线分流DOMAIN-SUFFIX,github.com,Group-DevDOMAIN-SUFFIX,githubusercontent.com,Group-DevDOMAIN-SUFFIX,openai.com,Group-DevDOMAIN-SUFFIX,anthropic.com,Group-DevDOMAIN-SUFFIX,netflix.com,Group-StreamDOMAIN-SUFFIX,nflxvideo.net,Group-StreamDOMAIN-SUFFIX,disneyplus.com,Group-Stream
# 办公与协作DOMAIN-SUFFIX,slack.com,Group-OfficeDOMAIN-SUFFIX,zoom.us,Group-OfficeDOMAIN-SUFFIX,notion.so,Group-OfficeDOMAIN-SUFFIX,feishu.cn,DIRECT
# 广告拦截RULE-SET,reject,REJECT
# 兜底策略GEOIP,CN,DIRECTFINAL,Group-Fallback,dns-failed
[Rule Set]private = https://raw.githubusercontent.com/Loyalsoldier/surge-rules/release/private.txtcn-domain = https://raw.githubusercontent.com/Loyalsoldier/surge-rules/release/direct.txtcn-ip = https://raw.githubusercontent.com/Loyalsoldier/surge-rules/release/cncidr.txtreject = https://raw.githubusercontent.com/Loyalsoldier/surge-rules/release/reject.txt
[Module]# 模块按需启用，建议仅加载必要模块模板中有几个设计细节值得展开。Group-Fallback 使用了 fallback 类型而非 url-test，两者的差异在于故障判定机制。url-test 定期对所有节点发起 HTTP 探测，选择延迟最低者，但探测成功不代表业务可用。fallback 类型在首个节点连续失败达到阈值后才切换，更适合对稳定性要求高于延迟的办公场景。tolerance 参数控制切换灵敏度，50 毫秒的容差意味着新节点延迟需低于当前节点 50 毫秒以上才会触发切换，避免在延迟波动时频繁跳变。
DNS 配置采用了分段策略。dns-server 指定国内明文 DNS 用于解析国内域名，encrypted-dns-server 用于解析需要防污染的域名，fallback-dns-server 在加密 DNS 超时后回退到系统 DNS。dns-fallback-system = true 这一行尤为关键，它确保在 DoH 服务不可达时不会导致整体解析中断。对于企业环境，建议将 encrypted-dns-server 替换为自建的 DoH 或 DoT 服务，避免依赖公共解析器带来的隐私与可用性风险。
规则集的引用顺序直接影响匹配性能。Surge 采用首次匹配即终止的机制，因此高频访问的域名应放在规则列表前部。private 规则集放在首位可以快速排除局域网流量，cn-domain 紧随其后处理国内域名，这两类规则覆盖了日常流量的绝大部分。GEOIP,CN,DIRECT 作为兜底直连规则放在 FINAL 之前，确保未被域名规则覆盖的国内 IP 流量不经过代理。FINAL,Group-Fallback,dns-failed 中的 dns-failed 参数表示当 DNS 解析失败时也交由该策略组处理，避免因解析超时导致的连接挂起。
关于策略组的嵌套深度，建议不超过三层。每增加一层嵌套，策略选择时的状态查询就多一次内存遍历。在节点数量超过 50 个的场景下，三层嵌套的切换延迟可能增加 2 到 3 毫秒。对于延迟敏感的业务，可以将常用节点直接放入一级策略组，减少中间层。
配置文件的版本管理同样重要。建议将配置文件纳入 Git 仓库，每次修改记录变更原因与生效时间。Surge 支持通过 surge-cli 工具进行配置校验，命令为 surge-cli --check-config /path/to/config.conf，该命令会输出语法错误与规则冲突警告。在企业部署中，可以将校验步骤集成到 CI 流程中，避免错误配置推送到生产设备。
对于需要管理多台设备的团队，Surge 的配置可以通过 iCloud 同步或企业 MDM 方案分发。MDM 方案的优势在于可以强制统一 DNS 与规则集来源，避免个别设备因配置漂移导致分流异常。在 配置教程保姆级指南 中有关于 MDM 分发的详细步骤。若团队需要自建规则集托管服务，专线百科 中关于 HTTP 缓存与 ETag 的章节提供了规则集更新的优化思路，通过设置合理的 Cache-Control 头可以减少重复下载带来的带宽消耗。
最后需要强调的是，任何配置模板都需要根据实际网络环境调整。节点延迟、DNS 响应速度、规则集覆盖范围都会随时间和地域变化。建议每月进行一次配置审计，检查规则集更新日志、节点可用性、DNS 解析成功率三项指标。若发现某机场节点连续多日延迟超过 300 毫秒或丢包率高于 5%，应及时在策略组中调整权重或更换上游服务。关于机场服务的评估方法，科学上网防跑路避坑指南 提供了可操作的检查清单，机场评测中心深度对比大全 则收录了主流机场的实测数据，可作为更换决策的参考依据。经过实测的稳定高速机场可参阅 2026 优质稳定高速机场推荐总榜，该榜单按季度更新延迟与带宽测试结果。