sing-box Windows TUN模式怎么配置？安装、导入与断网排查
简答：sing-box Windows TUN 模式建议按“安装匹配架构的 Desktop 客户端→导入配置→确认 tun、auto_route 和 route.auto_detect_interface→以权限足够的方式启动→检查虚拟网卡、路由和 DNS”的顺序操作。先用文中的完整测试模板验证 TUN，再替换为实际出站；如果启动后断网，优先回滚配置并检查出站标签、路由环回和系统代理是否重复接管。
定义：TUN 模式是通过虚拟网络接口和路由接管系统流量的方式，不等同于只让浏览器读取 Windows 系统代理。
先按这张清单做：安装、配置与启动的最短路径
本文是 Windows 客户端使用指南，仅用于帮助核对 sing-box 配置和连接问题，不代表任何客户端或配置文件的官方页面。官方 Desktop 客户端当前说明支持 Windows 10 及以上，并提供 x64、x86、ARM64 架构版本，可管理本地或远程配置并提供 TUN 透明代理功能。具体安装包和界面以当前发布页为准。查看 sing-box Desktop 官方说明。
| 阶段 | 要做什么 | 成功标准 |
|---|---|---|
| 1. 核对系统 | 确认 Windows 版本和系统架构 | 系统为 Windows 10 或更高版本，安装包架构匹配 |
| 2. 安装客户端 | 从官方 Desktop 页面进入 GitHub Releases，选择对应架构的安装包 | 客户端能够正常启动，未出现架构不兼容提示 |
| 3. 导入配置 | 导入本地 JSON 或添加远程配置 | 配置校验通过，存在 tun 入站和可用出站 |
| 4. 检查 TUN | 确认 auto_route 和 route.auto_detect_interface | 启动后创建虚拟接口，出站不会再次进入 TUN |
| 5. 验证流量 | 分别测试 IPv4、IPv6、DNS、浏览器外程序和命令行 | 结果与配置的接管范围一致，不只看浏览器是否能打开网页 |
如果只需要让支持代理设置的应用联网，系统代理模式可能更简单；如果希望覆盖不读取系统代理的程序，才考虑 TUN。两种模式不要一开始同时开启，否则出现断网时很难判断是 TUN、系统代理还是其他虚拟网卡在接管流量。
Windows 安装与架构选择：先装对客户端，再导入配置
- 查看系统架构。打开 Windows“设置—系统—系统信息”，查看“系统类型”；也可以在 PowerShell 执行
Get-CimInstance Win32_OperatingSystem | Select-Object OSArchitecture。常见结果包括 x64-based PC、ARM64-based PC 或 32 位系统。 - 选择官方 Desktop 安装包。官方页面列出的 Windows 架构包括 x64、x86 和 arm64。下载时不要仅凭文件名猜测架构，先以系统信息为准；官方页面将下载入口指向 GitHub Releases。查看官方系统要求和下载说明。
- 运行安装程序。安装前先保留现有配置副本。安装程序要求的权限、安装目录和首次启动提示可能随版本变化，不要把其他 GUI 的菜单路径套用到官方 Desktop。
- 首次启动并导入配置。使用客户端提供的本地文件导入或远程配置添加功能。导入后先看配置校验结果，再检查 TUN 入站、出站标签、路由默认出口和 DNS 设置。远程订阅中可能含有访问令牌，分享日志或配置前应先脱敏。
- 处理权限提示。TUN 涉及虚拟接口和系统路由，是否弹出管理员提示取决于客户端、配置和当前权限。若日志明确显示权限不足，先关闭客户端、备份配置，再使用“以管理员身份运行”复测；不要把关闭安全防护、清除文件隔离属性或修改系统策略作为默认步骤。
- 了解 Desktop 的运行方式。官方 Desktop 功能说明显示，SFW 会以 Windows 系统服务运行，工作目录位于
C:\ProgramData\sing-box-daemon。因此排查时应同时查看客户端界面和日志，不要只检查用户目录。查看 Desktop 功能说明。
如果你使用的是命令行内核或其他 GUI，安装包、配置目录和导入按钮可能不同。本文以官方 Desktop 的通用流程为主；其他界面只需寻找“本地配置、远程配置、启动配置、TUN、日志、系统服务”等同类功能，不把具体按钮名称视为所有客户端通用。
可直接校验的 Windows TUN 测试模板
下面是一份完整的最小测试配置：它包含本地 DNS、TUN、自动路由、严格路由、direct 出站和默认路由，目标是先验证 Windows 能否创建 TUN 并恢复基本网络。它不是带代理节点的订阅模板；确认 TUN 工作后，再把 direct 出站替换为实际存在的代理出站，并把 route.final 改为对应标签。
{"log":{"level":"info"},"dns":{"servers":[{"type":"local","tag":"local"}],"final":"local"},"inbounds":[{"type":"tun","tag":"tun-in","address":["172.18.0.1/30","fdfe:dcba:9876::1/126"],"auto_route":true,"strict_route":true,"dns_mode":"hijack"}],"outbounds":[{"type":"direct","tag":"direct"}],"route":{"auto_detect_interface":true,"rules":[],"final":"direct"}}
address：定义 TUN 虚拟接口使用的 IPv4 和 IPv6 前缀。不要改成与现有局域网、虚拟机或其他 VPN 冲突的网段。auto_route：让系统默认路由指向 TUN。它只说明路由接管已开启，不代表代理出站一定可用。strict_route：在 Windows TUN 场景下会影响非 TUN 接口上的 DNS 流量；如果虚拟机、多网卡软件或局域网访问异常，应记录原值后临时关闭对照。dns_mode：当前官方文档列出的值包括disabled、native和hijack。开启auto_route时，hijack是官方文档列出的默认行为；它不是对所有应用和网络环境都有效的绝对防泄漏保证。查看 TUN 字段和 DNS 行为。auto_detect_interface：让出站连接绑定到默认网卡，避免代理自身被 TUN 再次接管形成路由环回。也可以使用default_interface指定网卡，但两者不要无必要地同时设置。查看 Route 官方字段说明。
这份模板没有填写 mtu，因为官方字段文档没有要求 Windows 用户使用某个固定值。若出现特定网站打不开、长连接中断或大文件传输异常，应先记录默认行为，再单独测试 MTU，不能把固定 MTU 当作通用修复。
DNS 配置怎么写：默认逻辑与自定义地址要分开
最稳妥的第一轮测试是保留上面模板中的 dns_mode 为 hijack，不自定义 dns_address。官方文档说明，当 dns_address 未设置时，内核会使用 TUN address 中对应的后续地址，并按 hijack-dns 逻辑处理；这样可以避免读者只复制一半字段。
如果你确实要自定义 DNS 地址，需要同时在 route.rules 增加 DNS 劫持动作。官方示例采用“匹配 DNS 协议后执行 hijack-dns”的写法，下面是可合并到路由配置中的片段：
{"inbounds":[{"type":"tun","tag":"tun-in","address":["172.18.0.1/30","fdfe:dcba:9876::1/126"],"auto_route":true,"strict_route":true,"dns_mode":"hijack","dns_address":["172.18.0.2","fdfe:dcba:9876::2"]}],"route":{"rules":[{"protocol":"dns","action":"hijack-dns"}],"auto_detect_interface":true,"final":"direct"}}
dns_address 只是指定 DNS 服务器地址，不能单独证明 DNS 已被接管；自定义后必须确认对应的路由规则和 DNS 模块都能处理请求。官方规则动作文档将 hijack-dns 定义为把 DNS 请求交给 sing-box DNS 模块。查看 hijack-dns 官方规则动作。
Windows 上可以这样检查：先执行 ipconfig /all 查看 DNS 服务器，再执行 Get-NetAdapter 查看虚拟网卡，使用 route print 查看路由，最后用 nslookup example.com 或 Resolve-DnsName example.com 测试解析。判断时要分别记录 IPv4、IPv6 和 DNS 结果；查询成功只说明解析完成，不能单独证明请求没有经过其他接口。
系统代理、浏览器代理和 TUN 同时开启时怎么排查
| 测试顺序 | 设置 | 观察什么 | 结论范围 |
|---|---|---|---|
| 第一轮 | 关闭 Windows 系统代理和浏览器单独代理，只启动 TUN | 虚拟网卡、路由、命令行和浏览器是否都能按预期工作 | 判断 TUN 自身是否可用 |
| 第二轮 | 保持 TUN 关闭，只开启系统代理 | 读取系统代理的应用能否工作 | 判断普通代理链路是否可用 |
| 第三轮 | 按实际需求开启系统代理，但不要重复设置浏览器独立代理 | 是否出现重复代理、循环连接或某些应用异常 | 判断多层代理设置是否冲突 |
浏览器能打开网页，不等于命令行、UWP 应用、后台服务、IPv6 流量都经过 TUN。每次只改变一个开关，并记录“系统代理、浏览器代理、TUN、其他虚拟网卡”的原始状态。若启动 TUN 后完全断网，先停止 TUN并恢复备份配置，再检查 route.final 是否指向不存在的标签、auto_detect_interface 是否被关闭，以及其他 VPN 或虚拟网卡是否改变了默认路由。
查看网卡和路由时可以使用：
Get-NetAdapter：记录物理网卡和虚拟网卡的名称、状态。Get-NetRoute -AddressFamily IPv4：查看 IPv4 路由变化。Get-NetIPConfiguration：核对默认网关和接口配置。route print：保留启动前后的路由表，用于对比和回滚判断。
这些命令只用于观察，不要在没有明确路由目标、网关和回滚方案时手工删除系统路由。TUN 配置修改应优先通过客户端停止、恢复备份文件和重新启动完成。
版本字段速查：1.9、1.10、1.13.3、1.14 与 1.15 怎么看
| 版本节点 | 官方资料中可核实的变化 | Windows 用户怎么处理 |
|---|---|---|
| 1.9.0 | 官方 TUN 变化列表未将其列为 address 合并版本；该版本在迁移资料中另有 Windows 进程路径行为变化 | 不要因为教程写着 1.9 就继续使用旧 TUN 地址字段，先按当前内核文档校验 |
| 1.10.0 | inet4_address、inet6_address 合并到 address；对应 route address 和 exclude address 也合并 | 优先使用 address、route_address 和 route_exclude_address |
| 1.13.3 | 官方 TUN 变化列表没有把 1.13.3 列为新的 TUN 字段节点；官方更新日志记录的是其他发行变化 | 不要把 1.13.3 的普通更新误写成 TUN 字段迁移 |
| 1.14.0 | 新增 dns_mode、dns_address 等 TUN 字段；官方更新日志说明默认 hijack 会设置平台原生 DNS，并配合平台级 DNS 劫持机制 | 确认当前内核支持这些字段；自定义 dns_address 时增加相应 DNS 劫持规则 |
| 1.15.0 | TUN 使用新的 sing-tun TCP/IP 栈；旧 stack 字段被标记为弃用，官方迁移文档建议移除 | 从旧配置迁移时删除 stack，不要继续照抄旧版 stack: system |
官方 TUN 页面还列出：strict_route 自 1.13.3 起出现，address 自 1.10.0 起使用，dns_mode 和 dns_address 自 1.14.0 起使用。1.15.0 的主要迁移重点是 TUN 栈和 stack 弃用，而不是重新发明 Windows 的基本导入流程。查看官方迁移文档。
截至 facts.today，本文只采用官方文档能够核实的字段和版本变化；具体客户端构建号、安装包文件名和界面菜单如果未在当前页面中核实，应以发布页和客户端实际界面为准。
启动失败、断网和局域网异常：按现象回滚
| 现象 | 先查什么 | 判断标准 | 处理与回滚 |
|---|---|---|---|
| TUN 创建失败 | 管理员权限、配置校验、地址格式、其他虚拟网卡 | 日志不再出现权限、字段或地址错误，并出现虚拟接口 | 停止客户端，恢复备份；确认版本支持当前字段后再逐项添加 |
| 启动后完全断网 | route.final、出站标签、默认网卡检测 | 代理自身能建立出站，且出站没有重新进入 TUN | 优先恢复 auto_detect_interface；仍异常就关闭 TUN并恢复原系统代理 |
| 浏览器能用，其他程序不能用 | 是否只开启了系统代理，或 TUN 未真正接管 | 虚拟接口和路由存在，目标程序日志也出现连接记录 | 关闭浏览器独立代理，单独测试 TUN，再测试命令行和 UWP |
| DNS 解析失败 | dns_mode、DNS 服务器、hijack-dns 规则 | nslookup 或 Resolve-DnsName 能稳定返回结果 | 先恢复默认 DNS 逻辑；自定义地址时同步检查路由动作 |
| 局域网或虚拟机异常 | strict_route、局域网网段、其他虚拟接口 | 停止 TUN 后局域网恢复，说明接管范围存在影响 | 保留原配置，逐项测试 strict_route 和排除范围，不直接删除全部路由保护 |
回滚顺序建议固定为：停止 TUN→关闭客户端→恢复备份配置→确认 Windows 系统代理恢复原值→检查默认网关和路由→重新启动客户端。不要同时修改 MTU、DNS、分流和出站协议，否则无法判断是哪一项造成变化。
如果日志提示出站不存在，检查 route.final 或规则动作引用的标签是否与 outbounds 中完全一致；如果提示环回，优先检查 route.auto_detect_interface、route.default_interface 和其他 VPN 是否同时接管默认路由。官方 Route 文档明确说明，自动检测或指定默认网卡用于避免 TUN 下的路由环回。查看 Route 官方说明。
常见问题
sing-box Windows TUN 模式一定要管理员权限吗？
不能把所有客户端和配置都概括为必然需要管理员权限。TUN 涉及虚拟接口和系统路由，客户端可能根据运行方式请求提升权限；如果日志显示权限不足，先备份配置，再以管理员身份启动复测。官方 Desktop 还说明其 Windows 客户端会以系统服务运行，实际提示以当前客户端为准。
dns_mode 有哪些值？native 和 hijack 都能用吗？
官方 TUN 文档列出的值包括 disabled、native 和 hijack。native 主要设置平台原生接口 DNS；hijack 在此基础上增加端口 53 劫持逻辑。开启 auto_route 时，hijack 是官方文档列出的默认行为，但不应把它理解为对所有应用和环境的绝对防泄漏保证。
为什么 TUN 开启后会断网？
常见原因之一是 route.final 指向不存在的出站、代理出站被再次送入 TUN、权限不足、TUN 地址冲突或其他 VPN 改写了默认路由。先看日志和 route print，再停止 TUN、恢复备份；不要同时修改 MTU、DNS 和分流规则。
自定义 dns_address 后为什么还要写 hijack-dns？
官方文档说明，设置 dns_address 后需要配置 hijack-dns 路由规则处理发往这些地址的 DNS 流量。最小测试时可以不自定义 dns_address，先使用默认地址和 hijack 逻辑；只有明确需要自定义地址时，再把 protocol 为 dns、action 为 hijack-dns 的规则加入 route.rules。
系统代理和 TUN 可以同时开启吗？
可以存在同时开启的场景，但不建议把它作为第一轮排障方式。先关闭 Windows 系统代理和浏览器独立代理，只测试 TUN；再单独测试系统代理，最后按需求组合。浏览器能打开网页不能证明命令行、UWP、后台服务和 IPv6 流量都经过 TUN。
1.15.0 的 stack 字段还要保留吗？
官方迁移文档将 TUN 的 stack 字段标记为 1.15.0 起弃用，并建议移除以使用新的 sing-tun 栈。旧配置迁移前先备份，删除后重新校验；如果当前客户端仍提示字段兼容问题，以实际内核版本和官方迁移文档为准。