1. 先确认配置与内核已启动
Clash 客户端窗口能打开，不代表代理内核已经运行。首次配置应分开验证四件事：配置成功加载、本地端口正在监听、出站策略可用、目标应用确实把连接交给代理。按这个顺序检查，能避免把端口问题误判成订阅失效。
本文以桌面端常见的 HTTP/SOCKS 混合端口 7890 为教学示例。它不是所有客户端的固定默认值。ClashX、Clash Verge Rev 与其他使用 mihomo 内核的客户端，设置入口和覆盖机制可能不同；必须以当前客户端显示的有效配置与启动日志为准。
- 进入客户端的「配置」或「Profiles」，确认已选中一份配置，而不只是完成了订阅下载。
- 进入「代理」或「Proxies」，确认存在可选的代理节点与策略组。只有
DIRECT并不能证明代理订阅已生效。 - 打开「日志」或「Logs」，查找配置解析结果、监听地址，以及是否出现启动失败或端口绑定失败。
- 记录当前使用的内核类型、混合端口、运行模式和系统代理状态。后续每次只调整一项。
2. 混合端口：核对监听地址与占用进程
mixed-port 允许 HTTP 代理与 SOCKS 代理共用一个本地端口。浏览器的手动 HTTP 代理可以指向它，支持 SOCKS5 的程序也可以指向它。这里的“混合”不是把所有系统流量自动接管，更不表示本机所有应用都会使用代理。
下面是配置字段的最小片段，用于理解各项含义，不是一份可直接联网的完整订阅。已有配置不应重复追加同名顶层键；客户端若通过覆写生成配置，应在对应覆写入口修改，而不是编辑会被订阅更新替换的缓存文件。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info仅在本机使用时，先保持 allow-lan: false。检查日志中的监听地址是否为本地回环地址，例如 127.0.0.1:7890。实际绑定还受客户端与内核配置影响，不要仅凭一个开关推断监听范围。
Windows：用进程编号确认端口归属
在 PowerShell 中执行以下命令。第一条找出正在监听 TCP 7890 的进程编号，第二条可将编号映射到进程名称；替换示例编号 1234 后再运行。
Get-NetTCPConnection -LocalPort 7890 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess
Get-Process -Id 1234若端口属于另一款代理工具，应先正常退出那款工具，或为当前客户端换一个空闲端口。不要直接结束不认识的系统进程。修改为 7891 后，系统代理、浏览器独立设置和命令行测试也必须同步修改。
macOS 与 Linux：检查监听而不是只看窗口
# macOS：显示 TCP 7890 的监听进程
lsof -nP -iTCP:7890 -sTCP:LISTEN
# Linux：显示 TCP 7890 的监听套接字
ss -ltnp 'sport = :7890'部分进程信息需要相应权限才能显示。若查不到监听，而日志提示 address already in use，检查实际冲突的端口；若日志提示配置解析失败，先回到配置文件定位错误。网页打不开时反复切换节点，无法解决内核尚未监听的问题。
3. 出站模式：规则、全局与直连分别验证
模式控制的是“进入内核后的连接如何选择出站”，系统代理控制的是“应用是否把连接送进内核”。这是两个独立开关。即使选择全局模式，不遵循系统代理、也未被 TUN 接管的应用，仍可能直接联网。
| 模式 | 实际作用 | 首次排查用途 |
|---|---|---|
| 规则 / rule | 按规则顺序匹配，采用首条命中的策略 | 日常使用；检查目标域名命中哪条规则 |
| 全局 / global | 进入内核的连接使用全局策略所选出站 | 临时排除规则分流差异，仍需检查全局组选择 |
| 直连 / direct | 进入内核的连接走直连出站 | 比较本地网络路径，不用于验证代理节点 |
- 先使用规则模式，在实际命中的策略组中选定一个明确节点，暂时减少自动选择带来的变量。
- 打开目标网站，同时查看「连接」中的域名、命中规则和出站链。看到
DIRECT，应先判断是否符合规则设计。 - 若需要排除规则影响，短暂切换全局模式，并检查全局策略没有选择直连。测试结束恢复规则模式。
节点延迟测试成功，只能说明该次探测条件下存在可用响应，不等于所有网站、UDP 或应用协议都可用。遇到单个网站失败，要结合该连接的日志排查，不能仅凭延迟数字判断整份订阅失效。
4. 桌面系统代理：开关与实际地址一起核对
系统代理通常向支持该设置的应用提供 HTTP 代理地址，它不是全局网络隧道。首次测试可以先关闭 TUN，只验证系统代理链路；如果同时运行浏览器代理扩展、另一款 VPN 和 TUN，连接路径会更难判断。
Windows 11
打开「设置」→「网络和 Internet」→「代理」，查看「使用代理服务器」。客户端开启系统代理后，应核对地址与端口是否对应有效监听，例如 127.0.0.1 和 7890。若「使用设置脚本」同时启用，还需确认 PAC 脚本是否参与了代理选择，避免把脚本结果当作手动代理结果。
部分应用使用独立代理设置或 WinHTTP 配置，不一定跟随这里的设置。命令 netsh winhttp show proxy 查看的是 WinHTTP 代理，不是 Windows 设置页面当前用户代理的完整镜像；不要因为两者不同就盲目执行重置。
macOS
在较新的 macOS 中，进入「系统设置」→「网络」→ 当前联网服务 →「详细信息」→「代理」。检查网页代理（HTTP）、安全网页代理（HTTPS），以及需要时的 SOCKS 代理是否填写正确。ClashX 菜单栏中的系统代理选项，应与当前网络服务的结果一并核对。
可用 scutil --proxy 查看当前代理信息。HTTP 与 HTTPS 代理都指向混合端口是常见配置；这里的 HTTPS 代理设置通常仍是通过 HTTP CONNECT 建立隧道，并不要求把本地代理地址写成 https://127.0.0.1:7890。
Linux 桌面
以 GNOME 为例，进入「设置」→「网络」→「网络代理」，选择手动模式并核对 HTTP、HTTPS、SOCKS 的地址和端口。其他桌面环境入口可能不同，且并非所有程序都读取桌面代理设置。终端中的 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 也可能单独影响命令行程序。
5. Android、iOS 与 TUN：确认接管范围
移动端通常通过系统 VPN 接口接管流量，不能照搬桌面端“打开系统 HTTP 代理”的检查方法。Android 客户端首次连接时一般会请求建立 VPN 连接；iOS 客户端可能请求添加 VPN 配置。只有确认请求来自刚安装并正在操作的客户端，才继续授权。
- Android：确认 VPN 服务已启动，再查看是否开启分应用代理、应用绕过或仅代理选定应用。应用被排除后，即使客户端显示已连接，也不会按预期进入该代理路径。
- iOS：在「设置」→「通用」→「VPN 与设备管理」→「VPN」核对当前连接。具体策略组、规则与日志仍需回到客户端查看。
- 桌面 TUN：通常需要服务模式、管理员权限或对应系统授权。以客户端日志是否成功创建虚拟接口、配置路由为准，不能只看开关颜色。
- 其他 VPN：移动系统通常限制普通 VPN 服务同时运行。工作配置、企业管理与按应用 VPN 可能另有规则，切换前应确认设备管理要求。
TUN 接管 IP 流量后，仍要考虑路由、DNS 与应用排除设置。使用 Fake-IP 时，DNS 请求需要进入适当的解析链路，虚拟地址相关流量也需要回到内核处理。不要为了修复一个应用，直接把系统 DNS、Fake-IP、路由规则与 MTU 全部改动。
如果系统代理可用而 TUN 不可用，优先检查权限、虚拟接口、路由冲突与 DNS；如果 TUN 可用而浏览器的手动代理失败，优先检查本地监听和浏览器设置。这种分层比较比同时重装所有组件更有效。
6. 防火墙放行：区分本机访问与局域网共享
本机浏览器访问 127.0.0.1:7890，与手机通过局域网访问电脑代理，是两种不同场景。前者一般不需要为了“修复代理”额外开放公网入站端口；后者则要求客户端允许局域网连接、监听地址合适，并由防火墙允许可信网段访问。
- 先只在电脑本机完成测试，保持局域网共享关闭，排除网络隔离与入站规则因素。
- 确需共享时，确认手机和电脑处于可互访的同一网络，再使用电脑的局域网地址。手机里的
127.0.0.1指向手机本身，不是电脑。 - 在 Windows「Windows 安全中心」→「防火墙和网络保护」→「允许应用通过防火墙」中核对应用。只为实际需要的可信网络放行，不要一并开放公用网络。
- Linux 若启用了 UFW 或其他防火墙，按可信来源地址与具体端口设置规则。不要把关闭整个防火墙作为长期方案。
安全软件还可能拦截内核进程的出站连接或 TUN 驱动操作。应核对拦截记录中的可执行文件路径与时间，再决定是否授权。端口开放不等于节点可用，也不等于域名解析正常，仍需回到连接日志验证。
7. 用一次明确的请求完成验收
浏览器可能复用连接、读取缓存或使用扩展代理。为了先验证本地 HTTP 代理入口，可以在终端执行下面的命令。示例访问公开的文档示例域名，不代表任何代理节点的实测表现。
# Windows PowerShell：显式调用 curl.exe
curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com
# macOS / Linux
curl --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com--noproxy "" 用于避免现有绕过列表让本次请求跳过代理。连接超时设为 10 秒，总耗时上限设为 20 秒，便于固定测试条件。收到响应头表示这一次请求链路有响应；仍要在客户端确认它选择了代理节点还是直连。只看到 200 Connection established，还不能证明后续 TLS 与目标 HTTP 响应已经完成。
| 现象 | 优先检查 | 下一步 |
|---|---|---|
| 连接本地端口被拒绝 | 内核未启动、地址或端口错误 | 查监听进程和启动日志 |
| 客户端收到连接，但出站超时 | 所选节点、节点服务器解析、网络路径 | 固定节点后重试同一个目标 |
| 命令行成功，浏览器失败 | 浏览器独立代理、扩展、缓存与系统代理 | 核对浏览器实际代理来源 |
| 浏览器成功，部分应用失败 | 应用不遵循系统代理、UDP 或分应用设置 | 检查应用设置，再单独验证 TUN |
保留一份可复现的检查记录
最后记录客户端与内核版本、操作系统版本、端口、模式、策略组选择，以及测试发生的时间。需要进一步求助时，提供对应时间附近的错误行，比提交整份日志更容易定位。公开截图前隐藏订阅地址、令牌、节点凭据和个人网络信息。
- 配置已成功加载，本地混合端口有明确的监听进程。
- 规则模式下能解释目标连接命中的规则与出站策略。
- 系统代理或 VPN/TUN 接管方式已确认，不把两者混为一个开关。
- 防火墙授权范围与实际需求一致，退出客户端后不会遗留失效代理。
完成这四项后，再逐步开启自动选择、局域网共享或更复杂的 TUN 设置。需要补充安装与订阅操作时，可查看首次配置教程；具体术语可在术语表中核对。