客户端、系统与故障分类

补充更新：先按系统、客户端和故障证据分诊

更新于 2026-10-22 · netcli.net

简答：客户端、系统与故障分类适合已经遇到连接问题的读者。先确认设备系统，再匹配客户端和错误现象，按本机网络、代理/TUN、DNS、订阅、节点到目标网站逐层验证。

定义：这是一个按设备系统、客户端、故障现象和错误文本组织网络排障文章的分诊入口。

先做这一步：用“系统—客户端—现象—证据”定位文章

不要一开始就重装客户端或更换节点。先记录四项信息：设备系统、正在使用的客户端、具体故障现象、错误原文或日志片段。这样可以把“客户端配置错误”“系统代理未生效”“本地网络异常”“订阅内容无效”和“节点或目标网站问题”分开。

这张表只负责分流，不代表某一类现象只有一个原因；仍应以日志、命令输出和目标网站访问结果为准。

统一排查顺序：从本机直连到目标网站

1. 本地网络：先关闭客户端，确认普通网页能否直连打开；再切换 Wi-Fi、网线或手机热点做对照。
2. 客户端进程：确认客户端正在运行，配置已加载，代理端口没有被其他程序占用。
3. 系统代理与 TUN：Windows 同时注意应用代理和 WinHTTP。Microsoft 文档说明，WinHTTP 配置与 Windows Internet（WinINet）代理配置相互独立，可用 netsh winhttp show proxy 查看，用 netsh winhttp reset proxy 恢复直连。Microsoft Learn：netsh winhttp
4. DNS 与 TLS：比较系统解析和客户端解析结果，检查 DNS 模式、IPv4/IPv6、证书时间和是否存在 DNS 失败。
5. 订阅：在浏览器或命令行直接访问订阅地址，确认返回内容不是登录页、错误页或空内容；提交日志时必须隐藏订阅地址和 Token。
6. 节点与线路：不要只依据测速颜色判断可用性。直接访问目标网站，并记录连接、响应和日志结果。
7. 目标服务：如果只有一个网站或一个应用失败，应对比其他网站、其他应用和其他网络，避免把目标服务自身故障误判为客户端故障。

在 Android 上，系统 VPN 接口由 VpnService 管理，官方文档说明同一用户或工作资料通常只有一个活动 VPN；切换另一个 VPN 应用可能导致原有连接停止。Android Developers：VpnService

在 macOS 和 iOS 上，网络扩展通过包含路由和排除路由决定哪些流量进入隧道；因此“部分应用可用、部分应用不可用”时，应优先检查分流规则和系统网络扩展状态。Apple Developer：Routing your VPN network traffic

按系统平台选择排障入口

Windows

先检查客户端进程、系统代理、TUN 虚拟网卡和端口占用。若浏览器与命令行表现不同，分别检查应用代理和 WinHTTP；不要把“浏览器能打开”当作所有程序都已接管。

• 系统代理异常：进入 系统代理排障。
• 虚拟网卡异常：进入 Windows 虚拟网卡修复。
• 终端或脚本无法联网：进入 Windows Terminal 代理配置。

macOS

先确认客户端是否获得网络扩展或虚拟网卡权限，再检查路由、DNS 和多个客户端是否同时接管流量。若升级后突然无法启动或无法接管流量，保留错误原文，不要先删除全部配置。

• 网络扩展授权：进入 macOS 客户端权限排查。
• Clash Party 虚拟网卡：进入 虚拟网卡授权排查。
• 多个客户端同时运行：进入 客户端冲突治理。

Android

先确认系统 VPN 权限、是否有另一个 VPN 应用占用连接，再检查电池限制、TUN、DNS 和应用分流。Android 官方文档说明 VPN 应用需要用户授权，并且同一时刻不能并行运行多个活动 VPN。Android Developers：VPN

• 订阅导入后为空：进入 Android 订阅为空。
• TUN 开启后无法上网：进入 TUN 无网络。
• 协议或 QUIC 报错：进入 Android QUIC 排查。

iOS

先检查系统 VPN 配置是否已允许、订阅链接能否访问，再区分全局、分流和单应用规则。遇到订阅更新失败时，保留链接响应和客户端错误文本，避免直接反复点击更新。

• 订阅更新失败：进入 iOS 订阅更新排查。
• 需要确认不同应用走向：优先检查分流规则和网络扩展状态。

Linux 与路由器/OpenWrt

先确认服务进程、监听端口、路由表和 DNS，再检查防火墙、策略路由与 IPv6。涉及 TUN 时，Mihomo 文档将其描述为可用于接管系统流量、自动路由、DNS 劫持和按应用路由的入口；具体字段应以对应版本文档为准。Mihomo：Inbound configuration

按错误文本检索：先看信号，再决定下一步

如果错误文本不足以判断原因，建议记录：系统版本、客户端版本、内核版本、连接模式、复现步骤、错误原文、直连结果、切换网络结果和发生时间。不要提交订阅地址、Token、Cookie、私钥或未经脱敏的完整日志。

版本、格式与安全边界

同一故障在不同客户端、内核和系统版本上可能表现不同。填写反馈时应把客户端名称、客户端版本、内核版本和配置来源分开记录；查不到版本或字段的官方说明时，不要凭经验添加参数。

订阅链接属于敏感信息。公开截图前应遮盖域名中包含的令牌、完整 URL、账号标识、Cookie、私钥和本地路径。若需要展示配置，只保留与问题相关的字段，并替换服务器地址、用户名和密码。

若使用 Mihomo 的 DNS 或 TUN 配置，应直接对照其官方文档确认字段。Mihomo 文档列出了 DNS 的解析模式、IPv6 开关和 Fake-IP 等配置项，但具体行为仍取决于配置和运行环境。Mihomo：DNS configuration

排查后仍未解决：按这个模板反馈

可以复制下面的结构提交问题：系统/版本：；客户端/版本：；内核/版本：；连接模式：；问题现象：；错误原文：；直连结果：；切换热点结果：；其他节点结果：；DNS/IPv6 状态：；已尝试操作：；发生时间：。

反馈时优先附文本日志和脱敏截图，不要只写“连不上”或“速度慢”。如果只有一个应用失败，应补充该应用是否支持系统代理、是否需要单独设置代理，以及其他应用是否正常。

结尾推荐框为本站商业推广。

常见问题

客户端、系统与故障分类应该从哪里开始？

先选设备系统，再选正在使用的客户端，最后按具体现象或错误文本进入文章。若无法判断，先完成直连、切换网络和客户端日志三项最小验证。

为什么浏览器能打开，但其他应用仍然无法联网？

浏览器可能使用独立代理设置，而其他应用可能依赖系统代理、WinHTTP 或 TUN。Windows 可用 <code>netsh winhttp show proxy</code> 查看 WinHTTP 配置，并分别检查应用代理和系统代理。

节点全红是不是节点一定不可用？

不一定。测速失败可能只说明探针请求失败，不能替代目标网站访问验证。应直接访问目标网站、查看客户端日志，再对比其他节点和网络。

Android 和 iOS 的 TUN 或 VPN 为什么会突然断开？

先检查系统 VPN 权限、是否有另一个 VPN 应用占用连接，以及电池或后台限制；Android 官方文档说明同一用户或工作资料只能有一个活动 VPN。iOS 则应继续检查网络扩展、包含路由和排除路由。

提交排障截图时哪些内容必须遮住？

订阅完整 URL、Token、Cookie、账号标识、私钥、服务器密码和私人日志都应脱敏。只保留系统、客户端版本、错误文本、相关配置字段和必要的时间信息。

相关阅读

• 客户端排障文章
• 节点超时与网页打不开
• 订阅导入失败
• DNS 与泄漏排查
• 多个客户端冲突
• 订阅文本检查器

参考资料

1. Microsoft Learn：netsh winhttp
2. Microsoft Learn：Windows 客户端评估先决条件
3. Android Developers：VpnService
4. Android Developers：VPN
5. Apple Developer：Routing your VPN network traffic
6. Mihomo：Inbound configuration
7. Mihomo：DNS configuration