这类故障的现场很像：Karing 配置页已经有节点，延迟测试可能有结果，但浏览器报 DNS_PROBE_FINISHED_NXDOMAIN、ERR_NAME_NOT_RESOLVED，或 Karing 日志里出现 Failed host lookup。先把它当成三层问题处理：订阅格式、流量入口、DNS/规则。

Karing 的 GitHub Releases 页面已有 Windows 构建，GitHub API 标记的最新正式版本是 v1.2.18.2102，同时有 v1.2.19.2209 预发布；如果你的界面字段和这里不同，先按当前安装版的菜单名称找同类设置。

节点能显示，网页打不开是哪一层？

节点列表出现，不等于 Windows 已经把浏览器请求交给 Karing。把现象拆开看，能少走很多弯路。

现象更像哪一层第一眼看哪里
订阅更新返回 404、403、timeout订阅 URL 或鉴权浏览器打开订阅链接，看返回内容
节点能显示，系统代理不开时浏览器没变化Windows system proxyWindows 设置里的代理地址是否指向本机
system proxy 能通，TUN 一开就没网TUN 接管或虚拟网卡管理员权限、旧 TUN 软件、route print
IP 请求能通，域名请求失败DNS server 或 DNS ruleResolve-DnsName、Karing DNS 页面、日志
某些域名命中错误出口规则顺序Karing 连接记录和 sing-box route 命中

先别重装。退出 Karing 后普通网络必须恢复；普通网络没恢复前，继续改 DNS 或订阅只会把系统状态弄乱。

订阅链接返回的到底是什么格式？

Karing 官方 FAQ 写到支持 Clash、V2ray、Stash、Karing、Sing-box、Shadowsocks、Sub、Github 等配置类型。排错时不要只看链接后缀，直接看返回内容。

做两步：

  1. 把订阅 URL 粘到浏览器，确认返回的是配置文本，不是登录页、套餐页、错误页。
  2. 看前几行或结构：Clash/Mihomo 通常是 YAML，sing-box 是 JSON，V2Ray 批量订阅常见是编码后的节点列表。

如果浏览器看到 HTML，Karing 再怎么改 DNS 也不会把它变成可用配置。常见原因是订阅 token 失效、服务端要求登录、链接复制时少了参数，或把给另一个客户端的导出格式粘进了 Karing。

系统代理能通，TUN 失败时查哪里？

Karing FAQ 把 system proxy 和 TUN 分开说明：system proxy 只影响会读取系统代理设置的应用，TUN 才是更底层的流量接管。Windows 上排错时先用 system proxy 证明出站链路没问题。

先到 Karing 的端口设置里看本机 HTTP 或 SOCKS 端口，然后在 PowerShell 里测同一个网址：

curl.exe -x http://127.0.0.1:端口 https://example.com -I

能返回 HTTP 头，说明订阅、节点和本机代理入口大概率能跑。再打开 TUN，用同一个网址做对照：

curl.exe https://example.com -I
route print
Get-NetAdapter | Where-Object {$_.InterfaceDescription -match "TUN|Wintun|Karing"}

如果 system proxy 正常、TUN 异常，优先查这些点：

  • Karing 是否以足够权限启动。
  • 旧的 Clash、Mihomo、v2rayN、Hiddify 是否仍保留 TUN 适配器。
  • Windows 安全软件是否拦截了 karingService.exe。
  • sing-box TUN 相关的 strict_route、stack、auto_route 是否被配置覆盖。

多客户端共用同一份配置时，最容易把格式问题和 TUN 问题混在一起。可以先固定 Karing 的导入格式，再使用兼容 Clash / Singbox / V2Ray 的订阅承载多端配置；这样 Karing、Clash/Mihomo、v2rayN 各拿对应格式，不把订阅转换失败误判成 Windows DNS 故障。

DNS server、strategy 和 final 怎么排？

Karing DNS 手册把 DNS diversion rule、Proxy Traffic、Direct Traffic、final、FakeIP 等放在 DNS 页面里；sing-box 文档里则能看到 dns.servers、dns.rules、final、strategy 这些字段。Karing 界面不一定把字段名原样展示，但日志和导出的配置会露出同一套概念。

字段或页面项排错时看什么常见误判
DNS server当前 DNS 服务器是否可达把 DNS 服务器超时误判成节点不可用
final没命中 DNS rule 时用哪个 DNS server只改规则，不看兜底 DNS
strategyprefer_ipv4、ipv4_only、prefer_ipv6 等解析策略IPv6 不完整时仍优先拿 AAAA
DNS diversion rule不同流量是否走不同 DNS域名解析走了直连 DNS，连接走了代理出口
FakeIP是否把域名映射到虚拟 IP旧缓存或规则不匹配导致命中异常

Windows 家用网络里，最常见的可回滚改动是：临时关掉自定义 DNS server，改回 Karing 默认 DNS；如果只有 IPv6 域名失败，再对照 ipv4_only 或关闭 IPv6 相关选项。每次只改一项，测试域名固定用 example.com、github.com 和一个你实际打不开的域名。

规则顺序会怎样影响 DNS？

sing-box 的配置把 DNS 规则和路由规则分开。DNS 先决定域名怎么解析，路由再决定请求走哪个 outbound；两边任意一边命中错了，表现都可能是网页打不开。

排查顺序可以这样走：

  1. 在 Karing 连接记录里找目标域名，确认有没有请求记录。
  2. 有请求记录时，看命中的规则组和 outbound 名称。
  3. 没请求记录时，回到 system proxy 或 TUN 入口，不要急着改规则。
  4. 只有 DNS 失败时，进入 DNS 页面或导出配置看 dns.rules 和 final。
  5. 只有连接失败时，看路由规则、节点协议和端口。

不要把“全局模式能打开”直接当成规则坏了。全局模式绕开了一部分分流判断，它只能证明某个出口可用；真正要保留日常规则，还得回到命中记录看具体是哪条规则接住了域名。

日志里要找哪些词？

日志比测速结果更可靠。测速只说明某个探测请求完成，不能证明浏览器、DNS、规则和 TUN 都在同一条链路上。

日志或系统信号可能含义下一步
Failed host lookupDNS 查询失败换 DNS server 或看 strategy
timeout 出现在订阅更新订阅 URL 请求失败浏览器打开订阅 URL 对照
configure tun interfaceTUN 接口创建失败查权限、旧虚拟网卡、服务进程
连接记录没有目标域名请求没进入 Karing查 system proxy、TUN 或应用独立代理
命中 direct 但预期不是规则顺序或域名集命中错误看规则组、域名后缀、缓存

Windows 还可以补三条系统命令：

Get-DnsClientServerAddress
Resolve-DnsName example.com
netsh winhttp show proxy

netsh winhttp 只看 WinHTTP 代理，不等同于浏览器系统代理；它适合判断命令行工具和部分系统组件有没有被旧设置影响。

修好后怎样验收？

验收不要只点一下浏览器。用同一个节点、同一组域名，做四个状态对照：

  1. 关闭 Karing，普通网络可以打开 example.com。
  2. 只开 system proxy，用 curl.exe -x http://127.0.0.1:端口 https://example.com -I 返回 HTTP 头。
  3. 打开 TUN，不带 -x 的 curl.exe https://example.com -I 也能返回 HTTP 头。
  4. Karing 日志里能看到目标域名、DNS 查询和 outbound 命中。

最后重启一次 Karing。重启后订阅、DNS server、TUN 状态和当前节点仍能恢复，才算这次排错收尾。

Windows 之外的结果别直接套用

这篇只写 Windows 桌面端。iOS/macOS 走系统网络扩展，Android 走 VpnService，软路由或旁路由还会牵涉 DHCP、网关和局域网 DNS；这些环境不能直接照搬 Windows 的 route print 和 system proxy 判断。

没有实机验证的部分包括：企业终端管控、杀毒软件白名单策略、公司透明代理、Windows Insider 构建，以及 Karing 预发布版本里的菜单改名。遇到这些场景，先保留 Karing 版本号、Windows 版本、订阅返回内容、日志关键词和失败时间，再决定是回退正式版还是提交 GitHub issue。

相关阅读