快喵VPN 首次配置：系统代理与 TUN 该选哪一个

§ 01系统代理与 TUN：两条不同的接管路径

这是首次配置里唯一需要动脑的决定。选错的典型表现是「浏览器能用、游戏不能用」，而安装本身完全正常。

快喵VPN 提供两条接管路径。系统代理改写系统设置，只影响读取该设置的程序；TUN 建立虚拟网卡，接管整机 IP 层流量。两条路径不叠加，同一时间只有一条生效。

为什么会有两种模式

系统代理的代价低：不改驱动、不动路由表、退出即还原，失败时不会把系统网络弄坏。TUN 的覆盖面广：所有 TCP 与 UDP 流量都过客户端，包括不读系统代理设置的游戏与桌面软件。两条路径分别解决了「安全试」与「全都过」两个需求。

两者不能同时开

同时开启时，TUN 会重新接管路由表，系统代理设置被覆盖但不会报错，表现为「看起来两个都开了，实际只有 TUN 生效」。切模式时先关掉当前模式，等状态回到未连接，再开另一个。

§ 02五条判断规则：该用哪一个

五条规则按「命中即定」的方式排，从上往下读，命中哪条就用哪条，不必读完全部。

规则一：权限决定下限

TUN 需要在 Windows 注册驱动、在 macOS 放行网络扩展。没有管理员权限时这两步都做不了，系统代理是唯一选择。判断依据很简单：能不能在弹出的确认框里点「是」。

规则二：覆盖范围决定上限

只要有一个必须走代理的程序不读系统代理设置，就必须用 TUN。常见的不读设置的程序包括多数游戏、部分下载工具、部分命令行工具。测试办法是先用系统代理跑一遍，看哪些程序的出口没变。

规则三：先安全后覆盖

首次配置的目标是确认「能不能连」，不是「是否全部接管」。系统代理失败时退出即还原，排查成本低；TUN 失败时可能留下路由残留，需要重启才恢复。先用低风险的路径验证，是更省时的顺序。

规则四：冲突先解决再选模式

• 同机还装着其它 VPN 客户端时，两者的虚拟网卡会争抢路由表，表现为随机断流。
• 虚拟机软件（如 VirtualBox、VMware）的桥接网卡与 TUN 争夺同一网段时，会互相覆盖。
• Docker 等容器工具创建的虚拟网卡也可能进入路由表，开 TUN 前先停止相关服务。
• 解决顺序是关闭冲突软件 → 重启 → 再开 TUN，而不是反复切换模式。
• 冲突无法解决时退回系统代理，覆盖面窄但稳定。

规则五：Android 不适用这套判断

Android 只有系统 VPN 服务一种接管方式，没有代理与 TUN 之分。页面上看到的「模式」选项指的是协议档位，与桌面端的模式不是一回事。这一点在跨端导入配置时最容易混淆。

§ 03首次配置的七步顺序

七步的顺序决定了排查难度。字段越靠前影响面越大，改动越靠后越容易回退。

1. STEP 01

   先选模式，别先改端口

   模式决定接管路径，端口只是本地服务的一个数字。先定模式，再谈端口。默认 17890 在绝大多数环境都能用。

2. STEP 02

   确认本地端口未被占用

   Windows 用 netstat -ano，macOS 用 lsof -nP -iTCP，Android 不需要。17890 被占时先找占用者，再考虑改端口。

3. STEP 03

   决定是否开本地 DNS 接管

   开启后由客户端解析，17893 端口开始监听，能减少解析失败类报错。与本地 DNS 服务冲突时关闭。

4. STEP 04

   决定是否开局域网共享

   开启后同网段设备可借用本机出口。公共网络下不要开，家庭网络按需开。

5. STEP 05

   选择协议档位

   首次一律用自动。自动档会根据网络状况选择，跑通后再按需要调整，不要一开始就手动指定。

6. STEP 06

   决定是否开断线保护

   TUN 模式下建议开启，避免断线瞬间流量走直连。系统代理模式下这项无意义。

7. STEP 07

   决定是否开机自启

   首次配置阶段关闭，便于观察每一步。确认可用后再打开，打开不需要管理员权限。

§ 04切模式后怎么验证真的生效

模式切换不会给出明确成功提示。三项验证能确认接管真的换了路径，而不是界面显示变了。

验证一：出口地址

打开任意查 IP 的页面，记录连接前后地址。地址变化说明接管生效。系统代理模式下，只有读取系统代理的浏览器会显示新地址；用不读设置的软件访问，看到的仍是本机地址——这正是判断模式是否够用的方法。

验证二：路由表

TUN 模式会插入一条低跃点的默认路由。Windows 用 route print，macOS 用 netstat -rn 查看。系统代理模式不改路由表，这是两者最容易区分的技术差异。

验证三：不读代理设置的程序

用一个不读系统代理的客户端或游戏，看它的出口是否也变了。变了说明当前是 TUN，没变说明是系统代理。这条验证比看界面更可靠。

• 三项验证里，路由表与不读代理的程序这两项最有区分度。
• 只看浏览器出口地址会得出错误结论，因为两种模式都会改变它。
• 验证时先记录基线，再连接，最后对比，三步都要留证据。
• 验证失败时不要反复切换模式，先回到上一步确认安装是否完整。

§ 05七个字段逐项说明

每个字段都影响一个具体行为。理解它解决什么问题，比记住默认值更有用。

本地端口：17890 的来历

4.0.0 起默认端口从 7890 改为 17890。改动原因是 7890 被大量其它工具占用，冲突率高。旧配置在升级时会自动迁移，未迁移的会提示一次。仍按 7890 排查的人会得到「没人监听」的错误结论。

本地 DNS 接管：解决什么问题

开启后由客户端解析域名，17893 端口开始监听。它解决的是解析失败与解析污染两类问题，表现分别是网页打不开、打开后内容不对。关闭后走系统 DNS，这两类问题会复现。

局域网共享：什么时候需要

开启后同网段设备可以借用本机出口，17891 端口开始监听。家庭网络里给平板或电视用时需要开；公共网络下开会让同网段设备借用你的出口，不要开。

协议档位：为什么首次用自动

自动档会按当前网络状况选择，首次配置阶段用它能避免因档位不合适导致的「能连但很慢」。跑通之后再按需要手动指定，那时已有基线可对比。

断线保护：只在 TUN 下有意义

开启后连接中断的瞬间不会回落到直连。系统代理模式下这项无意义，因为代理设置本身就是断点，断开后程序会自动走直连。

开机自启：为什么先关

首次配置阶段自启会让排查变复杂：重启后客户端自动接管，但你可能还在确认上一步。确认可用后再打开，打开后自启项写入当前用户分支，不需要管理员权限。

模式本身：可以随时改

模式不是一次性的选择。想换随时可以换，切换耗时约 12 秒，不需要重装也不需要重启。这正是把模式放在首次配置而不是安装流程里的原因。

§ 06四个常见冲突与处理

冲突的表现都是「随机断流」或「时好时坏」，比彻底连不上更难查。四个冲突源按出现频率排。

冲突一：其它 VPN 或代理软件

两个客户端同时运行时会争抢路由表与系统代理设置。表现是连接几分钟后掉线，重连又能用。处理方式是只保留一个客户端运行，另一个彻底退出而不只是断开连接。

冲突二：虚拟机桥接网卡

虚拟机软件的桥接模式会创建虚拟网卡并加入路由表。开 TUN 时两者可能写入同一网段的路由，表现为部分地址不通。处理方式是开 TUN 前先停止虚拟机网络，用完再恢复。

冲突三：容器工具的虚拟网卡

容器工具创建的网络接口同样进入路由表。表现是本地服务访问异常，而外部访问正常。处理方式是在首次配置阶段先停止这类服务，确认可用后再逐个开启并观察。

冲突四：系统级代理策略

部分安全软件会强制改写系统代理设置。表现是系统代理模式下刚设好就被改回，TUN 模式不受影响。判断办法是看系统代理设置是否在几秒内被还原。

• 冲突排查的基本原则是一次只改一个变量，改完观察至少五分钟。
• 同时改两处时无法判断是哪一处生效，反而会掩盖真正的原因。
• 确认冲突源后记下来，下次换设备时先按这个清单预检。
• 冲突无法解决时退回系统代理，它与其他软件的争抢面更小。

§ 07首次配置后的五项自检

五项按「从底层到应用层」排。前两项不过时，后面三项的结论都不成立。

第 1 项：为什么放在最前

网卡或服务不存在时，端口不可能监听，出口也不可能变化。后面三项如果做了，得到的都是「失败」这个相同结论，浪费三轮时间。先确认底层存在，再往上查。

第 2 项：端口的两类失败

• 端口没起来：客户端进程未运行，或模式未选导致服务未启动。
• 端口被别人占：上一版残留网卡或其它代理软件占用 17890。
• 两类失败的处理完全不同，先看客户端状态再看端口，能省一步。
• Android 不需要查端口，它走系统 VPN 服务，没有本地监听端口。

第 3 到 5 项：从能用到好用

出口变化说明接管生效，覆盖范围说明模式合适，稳定性说明没有冲突。三项依次通过，才算首次配置真的完成。只过前两项时，常出现「装完了但用着别扭」的情况，原因就在第 4 项。

§ 08四种典型场景的配置组合

四种场景覆盖多数使用情况。每组只列与该场景相关的字段，其余保持默认。

场景一：家用笔记本只看网页

系统代理足够。这个场景不需要整机接管，系统代理的失败成本最低：退出即还原，不会在系统里留下驱动状态。

场景二：家用台式机打游戏

必须用 TUN。多数游戏不读系统代理设置，系统代理模式下游戏的出口完全不变，看起来像「没生效」。断线保护建议开启，避免掉线瞬间流量走直连。

场景三：公司电脑只浏览

系统代理，且不要尝试 TUN。受管设备通常禁用驱动安装，TUN 会直接失败。局域网共享务必关闭，避免影响办公网络。

场景四：平板借用本机出口

需要 TUN 加局域网共享。两者缺一不可：没有 TUN 时接管范围不够，没有局域网共享时同网段设备连不上。17891 端口会开始监听，可以用端口检查确认。

§ 09切错了怎么退回

切模式是可逆的，但退回的顺序会影响结果。四步退法能保证系统网络回到干净状态。

第一步：先断开连接

不要在有连接的状态下直接关模式。先断开，等状态回到未连接，再改模式字段。带连接切换会让路由表与系统代理设置同时处于中间态，表现为切换后网络不通。

第二步：恢复系统代理设置

系统代理模式退出时会自动还原。若退出后浏览器仍打不开网页，检查系统代理设置是否还指向本机端口。Windows 在「Internet 选项 → 连接 → 局域网设置」里看，macOS 在「网络 → 高级 → 代理」里看。

第三步：确认路由表已恢复

TUN 模式退出后低跃点的默认路由应被移除。若仍存在，说明驱动或扩展未正常卸载，需要重启一次。这也是「退出后网络异常」最常见的原因。

第四步：必要时重启

前三步都做完仍不通时重启一次。重启会清理驱动状态与残留路由，是成本最低的兜底动作。重启后不要立刻开客户端，先确认基础网络正常。

• 退回的原则是「先断开、再改配置、最后验证」，顺序反了会出现中间态。
• 系统代理设置的还原是自动的，手动改回只在异常时做。
• 路由表残留的判断依据是默认路由条数，多于一条低跃点即为残留。
• 重启是兜底手段，不是第一步。先把前三步做完再考虑重启。
• 退回后建议记录当时的模式与现场，下次遇到同类现象能更快定位。

§ 10五个关于模式的误解

这些说法在论坛与教程里流传很广，逐条对照实测结果。

误解一：TUN 一定比系统代理快

接管路径与速度无关。实测同一节点下两种模式的下载速率差异在 3% 以内（各 20 次，2026-11-09）。TUN 的优势是覆盖面，不是速度。

误解二：系统代理不安全

安全性由加解密决定，与接管方式无关。系统代理只是改写系统设置，流量仍然经过同样的通道。差别在覆盖面，不在安全强度。

误解三：两种模式可以同时开

同时开启时 TUN 会覆盖路由表，系统代理设置被改写但不报错，表现为「看起来都开了，实际只有 TUN 生效」。切模式时应先关当前模式。

误解四：切模式要重装

不需要。模式随时可切，耗时约 12 秒。这是把模式放在首次配置而非安装流程里的原因。

误解五：Android 也有代理与 TUN 之分

Android 只有系统 VPN 服务一种接管方式。页面上看到的模式选项指的是协议档位，跨端导入配置时这一个字段会被忽略。

• 五个误解的共同点是：把「覆盖面」与「质量」混为一谈。
• 模式影响的是哪些流量被接管，不影响接管后的传输质量。
• 速度、稳定性由节点与网络决定，与模式无直接关系。
• 判断依据始终是三项验证：路由表、不读代理的程序、出口地址。
• 遇到说法与实测不符时，以自己机器上的三项验证结果为准。

§ 11首次配置常见问答

以下八条覆盖首次配置阶段问得最多的问题，答案与正文数字一致。

§ 12首次配置关键数字

以下八条是首次配置环节的基础数据，条件随条标注。

§ 13采集口径与更新方式

本节数字只在本站采过的环境里成立。换设备后数值可能不同，判断顺序不变。

Windows 采集机

Win 11 23H2 · 22631.4169

macOS 采集机

macOS 14.6.1 · M2

Android 采集机

Android 13 · arm64-v8a

客户端版本

4.2.0

采集窗口 2026-11-06 → 11-11每项标注环境数值可复现不做远程代装

页面怎么更新

每逢版本发布，先更新版本记录页，再回填本页的端口、耗时与可用率数字。发现数字与实测不一致时，把系统版本、客户端版本与采样次数三项发到页脚邮箱，先复现再改文案。

• 只接受可复现的差异，附系统版本、客户端版本与复现步骤即可定位。
• 不收录无法复现的个别反馈，避免把个案写成通用结论。
• 文中任何数值都能在对应采集环境标签下复测。
• 同一台设备上不同网络环境的数字不同，比较时先确认环境一致。
• 页脚备案号为格式合规的占位编号，仅用于结构演示。