Clash 使用手册
订阅与规则分流配置

01 核心概念：一次连接经过哪些环节

客户端、内核与服务不是同一件事

Clash 生态里，客户端通常指带窗口和菜单的应用，用来管理订阅、切换模式、查看连接。内核是执行网络转发和规则匹配的程序；Mihomo 是这一生态中常见的内核。界面能打开，只能说明应用启动了，不代表内核已经加载配置，更不代表网络请求已经进入代理。排查时把这几件事拆开，往往比反复重装更有效。

代理服务提供远端连接所需的地址、协议和认证信息，订阅则是分发这些配置的方式。安装客户端不会自动产生可用服务。应从有使用权限的服务方取得兼容配置，并遵守当地法规、服务条款和所在网络的管理要求。订阅链接可能包含访问凭据，不能贴进公开讨论区，也不要交给来源不明的转换网站。

先理解请求入口，再理解出口

一个请求通常经历四步：应用发出请求，系统代理或虚拟网卡将请求送入内核，规则决定采用哪条策略，策略再选择直连或远端代理。系统代理是操作系统向应用提供的代理设置，是否遵从取决于应用自身。TUN 是虚拟网络接口，可以接管更多网络流量，但同样受路由、权限和排除项影响，并不是开启后所有程序都会按预期工作。

节点是一份具体的远端连接参数；代理组是管理节点或其他策略的集合。规则里写的 PROXY 往往是一个代理组名称，不是任何配置都自动具备的内置关键词。DIRECT 表示直连，REJECT 表示拒绝。看见规则指向某个名称时，要回到配置确认它是否存在，再检查这个组最终选中了什么。

DNS 与端口为什么会影响结果

DNS 是将域名解析成地址的机制。客户端可能使用系统解析，也可能启用内核自己的 DNS。解析发生在哪一层，会影响域名规则是否可用、地址规则匹配什么结果，以及请求是否需要先等待解析。看到连接失败，不能直接认定节点故障；域名无法解析、解析地址不可达和代理握手失败，是三个不同的问题。

端口则是本机服务的入口编号。混合端口通常同时接受 HTTP 代理和 SOCKS 代理请求，但不同客户端的默认值并不统一。本文示例使用 7897，实际操作始终以当前客户端显示的值为准。端口号相同不代表流量已进入内核，还要确认监听地址、应用配置，以及该端口有没有被另一个程序占用。

02 选择客户端：先确定平台与维护需求

优先选择适合当前设备的图形界面

首次使用可以优先考虑 Clash Plus，再根据平台和操作习惯对照其他客户端。不要仅凭窗口外观选择，也不要为了某个教程截图完全一致而安装旧软件。真正需要核对的是系统是否受支持、处理器架构是否匹配、订阅格式是否兼容，以及是否具备需要的系统代理、日志和 TUN 管理入口。安装包入口统一放在Clash 下载页。

Windows 可依次了解 Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu。macOS 可选择 Clash Plus、Clash Verge Rev 或 FlClash。Linux 的图形界面方案包括 Clash Verge Rev 和 FlClash。客户端都可能采用相近的内核能力，但服务安装方式、覆写机制和权限管理不同，因此本文以功能名称描述步骤，不把某个按钮的位置当作所有客户端的共同约定。

移动设备与桌面设备的区别

Android 可从 Clash Plus、Clash Meta for Android、FlClash、Surfboard 中按需选择。Surfboard 的配置体系与 Clash YAML 不完全相同，不能把所有 Clash 配置原样导入后期待字段逐一对应。先查看服务方提供的订阅格式，再选择客户端。移动系统通常通过 VPN 接口接管流量，应用首次连接时请求的系统授权，是网络接管流程的一部分。

iOS 可通过下载页进入 Clash Plus 的 App Store 页面，也可了解其官网 clashplus.io。手机上的后台限制、按应用接管能力和桌面的系统代理开关不是一套逻辑。跨设备学习时，应迁移规则思路和配置关系，而不是照搬菜单名。订阅可共用，也不代表每个设备都能共用完全相同的运行参数。

归档客户端与内核单独使用

Clash for Windows 和 ClashX Meta 已停止维护，下载页将它们作为归档选项展示。已有配置可以作为迁移参考，但新环境更适合先选择持续维护的方案。迁移时保留订阅来源、规则意图和代理组选择，不要直接覆盖新客户端整个数据目录。旧版本的数据库、缓存和服务注册信息，可能与新客户端不兼容。

Mihomo 内核包主要面向愿意自行维护配置、进程和权限的用户。它不等同于带完整窗口的安装程序，也不会自动替用户完成所有系统集成。若当前目标只是让浏览器按规则访问网络，先用图形界面完成主线更省事。需要迁移旧环境时，可配合阅读Clash for Windows 停更后的替代与迁移方案，逐项核对端口和代理设置。

这一阶段不用同时安装多款客户端进行“对比运行”。先选一个作为主客户端，把其他工具退出，避免它们同时修改系统代理、路由和 DNS。保留一条清晰的网络路径，后面的验证结果才有解释价值。

03 安装检查：系统架构、权限与本地端口

下载前确认系统和处理器架构

先打开系统信息，确认操作系统、处理器架构和可用存储空间。Windows 常见安装包面向 x64；macOS 要区分 Intel 与 Apple Silicon；Linux 还要区分发行版的软件包格式。名称里出现 ARM，并不说明所有 ARM 设备都能使用同一文件。以下载页具体提供的架构和客户端要求为准，不通过改扩展名或强行解包解决平台不匹配。

安装前退出旧的代理客户端和其他可能接管网络的工具。若旧应用开启了开机启动或常驻服务，仅关闭窗口可能仍保留后台进程，应从托盘菜单彻底退出。记录旧环境的混合端口和订阅来源，方便迁移后核对。此时先不要删除旧配置；等新客户端完成连接并通过验证，再决定是否清理旧环境。

按平台完成首次启动

Windows 运行安装程序后，先按普通应用启动。只有涉及服务安装或 TUN 权限时，才按客户端说明批准提升权限。不要把长期以管理员身份运行整个应用当作通用解决办法。macOS 将应用放入应用程序目录后，从系统认可的启动流程打开；遇到安全提示，先核对来源和提示内容，不要照抄来历不明的终端命令批量关闭系统保护。

Linux 使用与发行版匹配的软件包管理方式安装，留意依赖错误是否已经解决。图形窗口出现后，检查内核状态和日志入口是否可用。涉及桌面环境的系统代理设置时，不同桌面的表现可能不同；没有自动写入代理设置，不一定是内核不能运行。先区分应用启动失败、内核启动失败和系统集成失败，再针对对应层处理。

建立一次干净的启动基线

首次启动后，先查看设置中的混合端口、监听地址和允许局域网连接状态。只供当前电脑使用时，通常保持本机访问范围即可。本文把 127.0.0.1:7897 当作演示入口；如果实际显示其他端口，后面的应用设置和命令都要相应替换。保存配置后，确认客户端没有报告监听失败或端口占用。

# Windows PowerShell：查看示例端口的监听情况
Get-NetTCPConnection -LocalPort 7897 -State Listen

# macOS / 常见 Linux 环境：查看示例端口
lsof -nP -iTCP:7897 -sTCP:LISTEN

这些命令是按系统选择使用的排查工具，不要求在所有平台执行。查不到监听时，先确认内核是否已启动、是否已加载配置，以及实际端口是不是这个值。查到进程后，核对进程名称，不能只看到端口存在就判定正常。若提示命令不存在，可用系统自带的资源监视器或客户端日志确认，不必为一次检查额外安装工具。

安装阶段不需要立刻启用 TUN、开机连接和所有自动更新选项。先保证客户端正常启动、日志能读取、端口没有冲突，然后进入订阅章节。遇到故障时保留错误原文及触发步骤，比只记录“打不开”更有用。到此应得到一套最小、可复现的本地运行环境，而不是叠加许多尚未验证的功能。

04 订阅导入：从链接到实际运行配置

取得兼容配置，再执行更新

订阅是一个可更新的配置来源，常见形式为远程链接，也可能是本地 YAML 文件。先向服务方确认它适用于哪个客户端或内核，再打开客户端的订阅、配置或 Profiles 页面，选择新增远程配置。填入容易识别的名称，粘贴完整链接，保存后执行更新。避免漏掉链接末尾参数，也不要把网页里的显示标题当成实际订阅地址。

更新成功后，通常还需要选中该配置并启用。下载完成和配置生效是两个动作：订阅列表里的更新时间变化，不代表运行内核已经切换。观察当前配置名称、内核日志和代理组是否出现；如果仍看到旧的组名，先确认启用状态。某些客户端支持多个订阅同时管理，但实际运行配置如何合并，需要按它自己的配置机制理解。

分清订阅文件、覆写层和运行结果

订阅原文是服务方下发的数据；覆写是客户端在加载时补充或修改的内容；运行配置是内核最终接收的结果。手动编辑下载缓存，下一次更新可能就会被覆盖。需要长期保留的规则、端口或 DNS 设置，应优先放在客户端提供的持久覆写入口，并确认它是在订阅前、订阅后还是按字段合并执行。

不是所有远程配置都包含完整规则。有的只提供节点，需要客户端的模板补齐代理组和规则；有的已经带有 DNS、规则提供器及完整策略。导入之后先检查结构，不要为了套用某段教程直接删掉原配置。尤其是代理组名称与规则目标存在引用关系，改组名却不改规则，会让内核拒绝加载或让部分策略失效。

# 结构示例：用于认识字段，不是代理服务配置
mixed-port: 7897
allow-lan: false
mode: rule

proxies: []

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,PROXY

上面的 YAML 可以说明配置关系，但没有远端节点，所有请求最终都会直连。它适合阅读和检查字段，不用于验证代理服务是否可用。真实订阅中的服务器地址、密码、协议和证书参数应由有权限的来源提供，不要从教学片段拼凑。YAML 使用空格缩进，同一层级保持一致；制表符、中文冒号和不成对引号都可能造成解析错误。

更新失败时按错误类型处理

若提示网络超时，先确认当前网络能否访问订阅服务，再检查是否要求通过已有代理更新。若返回认证失败，核对链接是否过期、服务是否有效。若返回内容是网页而非配置，可能打开了登录页、错误页或跳转页，应向服务方确认正确入口。若下载成功却解析失败，重点看字段兼容性和错误行，而不是反复更换节点。

本地导入适合迁移和离线备份，但通常不会自动跟随服务方更新。远程订阅则应结合服务有效期和更新频率使用，避免过于频繁地手动刷新。更新前保留一份可恢复的本地配置；更新后验证代理组、规则和连接是否仍正常。分享日志或截图时遮住订阅链接、服务器认证信息及个人访问记录，不能只遮住名称就认为已处理完毕。

05 代理模式：入口开关与路由决策分开设置

规则、全局和直连分别控制什么

代理模式决定进入内核的请求如何选择出口，不负责保证所有应用都把请求交给内核。规则模式按配置中的规则逐条判断，适合日常分流。全局模式将进入内核的请求交给全局策略，适合临时缩小排查范围。直连模式让进入内核的请求直接连接目标，适合对照测试。切到全局，并不会让原本绕开系统代理的应用突然被接管。

全局模式也不等于某个固定节点。切换后要检查全局策略当前指向哪个组或出口。规则模式则需要检查每条规则引用的策略组选择。若某个组包含 DIRECT，选择它就意味着直连，即使界面仍显示规则模式。判断一次请求的实际行为，要看连接链和规则命中结果，不能只看首页的模式文字。

完成第一次可解释的连接验证

先启用规则模式，在代理组里选择一个有权限使用的出口，再开启系统代理。打开一个需要验证的网页，同时观察连接页面。如果没有新连接，优先检查浏览器是否使用独立代理设置、扩展是否覆盖配置，以及请求是否已被缓存。可以重新打开页面触发新请求，但不要把浏览器已有连接误当作切换后的结果。

若连接出现，展开详情，确认目标域名、命中规则和最终策略。网页能打开只是结果之一：可能是直连成功，也可能代理生效。应选择已知预期路径的目标进行对照，例如配置里明确设为直连的测试域名，以及明确设为代理的目标。不要用单个网页加载成败推断整套网络环境，更不要将外部页面显示的地区当作唯一证据。

为不遵从系统代理的应用显式设置入口

有些命令行工具不会自动读取桌面的系统代理。此时可以在工具自身配置代理，或为单次命令明确指定本地入口。下面的请求使用示例混合端口；端口不同就替换对应数字。它用于检查 HTTP 代理入口，不能据此推断 UDP 或 TUN 同样正常。请求结果还会受到目标站点、当前网络和所选策略影响。

curl --proxy http://127.0.0.1:7897 --head https://example.com

若命令提示无法连接本机端口，先回到安装章节检查监听。若已经连上代理但远端握手失败，再检查出口、认证和网络限制。需要临时全局测试时，记下原模式和代理组选择，完成后恢复规则模式。切换模式通常只影响新的连接，旧的长连接可能继续使用原路径；必要时关闭对应连接，再重新发起请求观察。

这一阶段形成一个固定习惯：先确认“进没进来”，再确认“按什么规则走”，最后确认“出口能否工作”。如果入口都没有流量，调整规则不会解决问题；如果命中规则正确却握手失败，继续改规则也只会增加变量。需要更短的操作顺序时，可返回入门指南，按主线逐项复现。

06 规则分流：从首条命中到持久覆写

从上到下，命中后停止继续匹配

规则列表不是把所有条件都计算完再综合投票。通常情况下，内核按从上到下的顺序检查，第一条匹配的规则决定策略，后面的规则不再参与这次决策。越具体、越需要优先执行的例外，应放在覆盖范围更大的规则前面。MATCH 是兜底规则，通常放在末尾；若提前出现，后面的规则就没有机会处理对应请求。

DOMAIN 匹配完整域名，DOMAIN-SUFFIX 匹配某个域名及其子域名，DOMAIN-KEYWORD 按域名关键词匹配。它们的粒度不同，不能为了少写几个字就随意互换。尤其是关键词规则，覆盖范围可能超出预期。希望只处理某个主机时，完整域名规则通常更容易验证和维护。

# 假定现有配置中存在名为 PROXY 的代理组
rules:
  - DOMAIN,docs.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

在这段顺序中，docs.example.com 先被完整域名规则设为直连，其他符合后缀的域名交给代理组。私有地址规则处理指定地址段，no-resolve 表示不为了这条地址规则主动触发域名解析；当请求已有目标 IP 时仍可匹配。不要把它理解成整个配置关闭 DNS，也不要把所有地址规则都机械地追加这个选项。

地址规则与规则集的适用边界

IP-CIDR 用于 IPv4 地址段，IPv6 地址段通常使用 IP-CIDR6。GEOIP 根据地址数据库判断，IP 归属地并不等价于公司所在地或访问者地区。数据库也可能变化。规则是否需要解析域名、是否使用已有地址，会影响表现，因此地址规则排在域名规则之前时，要特别关注 DNS 行为和命中日志。

RULE-SET 引用配置中已声明的规则提供器，适合把一类规则独立维护。它不是一个远程链接直接写进规则列表就能使用的缩写；提供器名称、来源、格式和行为类型必须相互对应。文本域名列表与经典规则列表的写法不同，错误混用可能导致加载失败或规则无效。新手应先理解几条本地规则，再引入外部规则集。

修改运行结果，不只修改下载缓存

新增规则时，先确定客户端提供的是前置规则、后置规则还是整体覆写。如果把自定义规则追加到已有 MATCH 后面，语法正确也可能永远不生效。保存后检查最终运行规则，而不仅是编辑框里的文本。若代理组名字包含空格、标点或非英文字符，要原样引用，不能凭印象缩写；目标名称不存在时，应先修复引用关系。

每次只加一条容易验证的规则，重新加载配置，再发起新连接，检查连接详情是否命中新规则。若旧连接仍在，先关闭对应连接或重启发起请求的应用。若依然不命中，检查看到的是域名还是 IP、前面有没有更宽的规则、应用是否绕过内核，以及覆写是否真的进入运行配置。这样可以逐步定位问题，而不是一次加入整份规则后无从判断。

07 TUN 模式：扩展接管范围与 DNS 联动

什么时候需要 TUN

如果浏览器已能按规则连接，而某个应用仍不遵从系统代理，可以先检查该应用是否支持单独配置 HTTP 或 SOCKS 代理。没有合适入口、又确实需要接管更多网络请求时，再考虑 TUN。它通过虚拟网络接口和路由把流量送入内核，比修改系统代理涉及更多系统层行为，因此必须在基础连接已经正常的前提下启用。

启用前先记录系统代理状态、当前 DNS 和其他 VPN 工具状态，并确认有退出后的恢复路径。关闭可能争抢默认路由的其他接管工具，按客户端要求安装服务或批准权限。不要同时开启多套虚拟网卡接管后再判断哪一套出了问题。移动端的 VPN 接口与桌面 TUN 的配置入口不同，不能照搬桌面 YAML 来覆盖手机的全部设置。

把接口、路由和解析一起理解

TUN 能收进流量，不代表解析链路就自然正确。应用可能通过系统 DNS、加密 DNS 或自身解析器获得地址；内核也可能接管部分 DNS 请求。若域名信息没有进入预期链路，某些域名规则的表现会与系统代理模式不同。遇到“直输地址可用、域名不可用”，应优先检查 DNS，而不是马上更换所有出口或修改所有规则。

# Mihomo 字段示例；是否需要填写应以客户端的 TUN 管理方式为准
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

这段配置展示自动路由、出口接口检测和 DNS 接管字段，不是一份独立可运行的完整配置。图形客户端可能自行生成这些字段，优先通过它的设置界面管理，避免重复覆写。any:53 不表示自动处理所有形式的加密 DNS；应用通过 HTTPS 发出的解析请求不能简单等同于传统的五十三端口查询。具体行为还取决于 DNS 配置和路由范围。

理解 Fake-IP 与真实地址解析

Fake-IP 是一种给域名分配内部映射地址、再由内核关联域名的工作方式，目的不是把目标服务器真的搬到这个地址。使用时，系统工具显示的地址可能不是网站的真实公网地址，因此不能仅凭一次解析结果认定被错误劫持。某些应用依赖真实地址或特殊发现机制，可能需要排除指定域名；排除范围应尽量精确，不要直接关闭整套 DNS 逻辑。

切换 DNS 工作方式后，系统或应用缓存可能仍保存旧结果。先结束相关连接、重新发起解析，再观察日志；必要时按系统文档刷新 DNS 缓存。局域网打印、共享目录和设备发现异常时，检查私有网段路由、局域网域名解析及排除规则。不能把所有局域网问题都归结为节点故障，也不应通过开放整个监听范围来修复解析问题。

验证时分别测试浏览器、目标应用和局域网资源，并在连接页观察它们是否进入内核。若只有一个应用失败，检查它自身协议与代理支持；若所有应用都失败，优先检查接管链路。退出客户端后还要确认系统网络恢复正常。完成这些对照，才适合启用自动启动和自动接管，不能只凭某个网页短暂打开就认定配置稳定。

08 日常维护：更新、备份与分层排查

把三类更新分开处理

客户端更新、内核更新和订阅更新分别改变不同内容。客户端更新影响界面及系统集成；内核更新可能影响协议、规则和 DNS 行为；订阅更新主要影响服务方下发的节点及规则。不要把三项同时更新后才开始验证，否则出现变化时很难定位来源。按需逐项进行，每次记录操作前后的模式、配置名称和关键开关。

更新前保存可恢复配置，阅读与当前用法有关的变更说明。订阅带来的字段可能需要较新的内核支持，旧客户端也可能无法正确管理新内核的能力。遇到兼容错误时，先确认客户端和内核的组合，再考虑是否回退；不要从多个来源混装不明文件。恢复备份时同样要核对客户端识别的配置格式，而不是直接覆盖所有内部数据。

备份需要保留什么

一份有用的备份至少包括订阅来源、持久覆写、自定义规则、代理组选择，以及端口、TUN 和 DNS 的关键设置。订阅缓存可以作为临时恢复材料，但不能代替订阅来源和自定义内容。截图便于记忆开关，却不适合恢复长规则。把配置导出为文本，并附一小段操作说明，通常比只保存应用目录更容易迁移。

备份中可能含有可访问服务的凭据，应放在有访问控制的位置，跨设备传输时避免公开分享。电脑与手机的订阅链接可以相同，但端口、接口、缓存路径和 TUN 参数未必通用。多设备同步建议先同步“服务与规则意图”，再分别设置系统层参数。具体做法可参考电脑与手机共用订阅的几种同步方式。

用一次只改一个变量的方式排错

先确认不经过代理时基础网络是否可用，再确认内核是否启动、端口是否监听，然后观察目标请求的命中规则，最后检查远端连接。每一步都保留结论。临时切全局是为了对照规则因素，不是日常故障的统一答案；临时关闭 TUN 是为了区分接管问题，也不代表 TUN 必须永久停用。排查结束后恢复原设置并重新验证。

日志级别以满足当前排错为准。需要详细信息时短暂提高级别，复现一次后保存相关片段，再恢复日常设置，避免长期积累大量访问记录。向他人求助时说明系统、客户端、当前模式、接管方式和完整错误现象，提供经过遮挡的必要日志。不要直接上传整份订阅，也不要把不相关的浏览历史一起打包。

延迟测试是辅助观察，不是完整体验的承诺。测试地址、握手过程、目标站点和带宽需求都会改变结果。若测试正常但实际应用卡顿，应针对应用的目标连接检查，而不是只反复点击测试。关于测试含义，可阅读url-test 延迟与实际体验差异，避免把一个数值当作整个出口质量。

09 进阶路线：代理组、规则集与可恢复配置

先完善策略结构，再增加自动化

基础连接稳定后，进阶的目标不是让配置尽可能长，而是让选择、更新和回退更清楚。先给日常使用、特定服务和直连例外建立明确的策略边界，再考虑自动选择。一个名称清楚、层级较少的代理组，比多层互相引用更容易解释。建立代理组前先写下它要解决什么需求，以及发生问题时应退回哪个出口。

select 代理组由用户手动选择，适合需要固定出口的场景。url-test 根据指定地址的测试结果选择候选项；fallback 按候选顺序和可用状态进行切换。不同组的选择逻辑不一样，不能都理解成“自动选最快”。测试请求本身也有网络成本，应按实际需要设置检查周期，不必为了界面变化频繁测试。

# 配置片段：proxies 中需先有同名节点
proxy-groups:
  - name: 日常选择
    type: select
    proxies:
      - 自动选择
      - DIRECT

  - name: 自动选择
    type: url-test
    proxies:
      - 出口甲
      - 出口乙
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

这里的“出口甲”和“出口乙”是示例引用名称，使用前必须替换成现有配置里真实存在的节点名。测试地址也应选择当前环境允许访问、适合持续检查的目标。interval 是检查间隔，tolerance 用来降低因小幅波动而频繁切换的可能；这些参数不提供速度保证。需要稳定会话的应用，还应考虑出口切换对登录和长连接的影响。

把规则集当作独立依赖管理

引入规则提供器时，记录来源、行为类型、更新方式和引用位置。远程规则发生变化后，实际分流也会变化，因此“配置文件没有改”不代表运行行为永远相同。为重要的自定义例外保留前置规则，并定期确认规则集仍能更新。出现下载失败时先看提供器状态，不要仅凭代理组正常就认定所有外部依赖都已加载。

扩展 DNS 和嗅探功能前，也要有明确问题。嗅探是从部分协议流量中尝试取得域名等信息，能力受协议和加密方式限制，不是所有连接都能恢复域名。若当前规则已经可靠，就不必为了功能列表完整而开启所有选项。每增加一项能力，都应记录它处理哪类请求、带来哪些边界，以及关闭后如何恢复原行为。

形成可复现的配置变更流程

建议把变更分成四步：复制当前可用配置，做一项小修改，验证语法及运行结果，记录结论后再保留。若使用独立 Mihomo 内核，并且终端可以找到该程序，可以用下方命令检查配置。图形客户端用户也可先使用客户端提供的配置检查功能。语法检查通过只代表配置能被接受，仍需要实际连接验证规则与出口。

mihomo -t -f config.yaml

进阶练习可以依次完成：为一个域名添加直连例外，为一类服务建立独立策略，验证一个规则集的更新，再设计一份能恢复的备份。每项完成后，检查运行规则和连接链是否符合预期。选择出口时，可结合延迟、倍率、地区与协议的对照方法，但不要用单次测试替代长期实际观察。