QuickQ连接设置支持哪些网络模式？

出差途中最容易踩的坑，往往不是节点挂了，而是「模式选错了」。一位做跨境电商的读者描述过这样的场景：笔记本上的 QuickQ 显示已连接，浏览器却一直转圈，客户后台打不开，会议软件也连不上。他重装客户端、换了几个节点、把电脑重启两遍，问题依旧。最后发现症结在一个不起眼的地方——连接设置里选中的是一个「全部流量都走客户端」的选项，而他当时所处的酒店网络对非常规流量有额外限制，改回按规则分流后立刻恢复。这类事故的共同点在于：很多人把连接设置当成一个开关，而它实际上是一组彼此影响的参数。所以「QuickQ 连接设置支持哪些网络模式」这个问题，答案不是列几个名词，而是要把「流量往哪走」「用什么协议走」「域名怎么解析」这三件事拆开看；这三件事，也分别对应后文要展开的三层结构。

一、先厘清边界：客户端里的「模式」其实分三层

很多人以为「网络模式」只有一个开关，实际使用中它至少叠了三层含义。第一层是流量走向：哪些流量交给客户端处理，哪些保持直连。第二层是传输方式：在已经决定转发的流量里，用什么样的底层协议封装。第三层是解析与规则：域名交给谁解析、规则表从哪里来、命中不到时走哪个兜底分支。这三层任意一层配置不当，表现都可能是「连上了但上不了网」，而排查方向完全不同。把这三层分开，是后面所有判断的基础；否则很容易在同一个现象里反复换节点，却始终没有碰到真正的原因。

1.1 第一层：流量走向

流量走向解决的是「谁被接管」。常见的三种取值是：全部接管、按规则接管、完全不接管。全部接管的好处是行为可预期——你看到的所有出口都来自同一个地方；代价是本地服务、局域网设备、部分依赖内网认证的办公系统可能一并被带走，从而出现「代理没坏，但打印机连不上了」这种看似莫名其妙的故障。按规则接管则相反，它对日常混合访问更友好，但规则覆盖不到的域名会被漏掉，表现成「有的网站快、有的网站慢」。完全不接管的价值主要在于排查：当你怀疑是客户端本身导致的问题时，先切直连，看现象是否消失。经验性观察是，同一套配置在家庭网络里正常、换到酒店或企业网络就失灵，往往不是节点变差了，而是流量走向与当前网络限制不匹配。

1.2 第二层：传输协议与接管方式

第二层常被忽略。同样叫「开启」，有的实现是通过系统代理（HTTP/SOCKS）让应用主动把流量交出来，有的则是通过虚拟网卡（TUN）在网络层接管。两者的差别很实际：系统代理只对「愿意读取系统代理设置」的应用生效，浏览器通常没问题，但某些桌面客户端、命令行工具、甚至部分游戏启动器会直接绕过它；虚拟网卡覆盖面更广，代价是需要更高的系统权限，并且可能与本机已安装的其他网络工具抢占路由。经验性观察是：如果你遇到「浏览器能用、某个专用软件不能用」，优先怀疑系统代理的覆盖范围，而不是节点质量。判断时可以先用一句话自问：出问题的应用，到底愿不愿意读取系统代理？

1.3 第三层：DNS 与规则来源

DNS 是「无法上网」的高频元凶。域名解析如果仍然走本地运营商，可能出现解析结果与实际出口不匹配的情况——流量走了远端，域名却解析到了就近的 CDN 节点，于是页面加载极慢甚至超时。规则来源则决定了「智能」到底智能到什么程度：规则表是内置的、可更新的，还是允许用户自定义的，这直接影响你能否为某一家公司内网、某一个测试域名单独开例外。这一层通常在客户端的「高级」或「更多设置」里，不在主界面上，所以最容易被跳过。如果发现解析结果与当前出口明显不匹配，就值得停下来检查这一层，而不是继续在节点列表里反复试错。

二、主流模式的横向对比：谁适合谁

下表整理的是代理类客户端普遍存在的模式分类，用于建立判断框架。它不是 QuickQ 某一版本的菜单截图，实际客户端里呈现的选项名称、数量与组合方式会随平台和版本变化，请以你安装的版本为准。先建立框架，再看具体菜单，会更容易对号入座。

从这张表能看出一个关键判断：没有「最好的模式」，只有「与当前网络环境匹配的模式」。在家庭宽带下表现良好的配置，搬到限制更严的企业网络或酒店网络里，可能立刻失灵。所以与其问「哪个模式最强」，不如问「我现在最需要保证的是什么」——是某个后台必须打开，还是整台机器的所有流量都要一致出口，抑或只是想让浏览器快一点。换句话说，模式选择本质上是场景匹配问题，而不是性能排名问题。

三、决策树：四个问题选定模式

把选择过程压缩成四个问题，绝大多数场景都能落到明确答案上。建议按顺序回答，不要跳步；顺序本身就是为了先排除影响面最大的因素。

1. 这次使用是否涉及内网资源？需要访问公司内网系统、NAS、局域网打印机、本地开发服务（如 127.0.0.1 上跑的服务）时，不要选全部转发，选按规则分流，并为内网地址段保留直连。
2. 目标应用是否读取系统代理？如果只有浏览器出问题，系统代理形态通常够用；如果是某个专用客户端、命令行工具或游戏启动器，多半需要虚拟网卡形态才能覆盖。
3. 是否需要统一出口做验证？比如排查「到底是不是本地网络封了某个端口」，此时临时切到全部转发，观察现象是否变化，是最快的二分法。
4. 故障是否只在某个特定应用上出现？如果是，问题大概率在规则层或该应用自身的代理设置，而不是全局模式选择。此时先补规则，别急着换模式。

举个具体例子。一位做独立站运营的读者反馈：白天在办公室用按规则分流一切正常，晚上回家后同样的配置下，后台图片上传始终卡在进度条。按上面四步走——不涉及内网（排除第一条），浏览器本身读取系统代理（第二条不成立），异常只出现在上传这一个动作上（第四条命中）。沿着规则层排查，发现上传走的域名被一条过宽的规则匹配到了直连分支，补上例外后恢复正常。整个过程没有换过节点，也没有重装客户端。这个例子说明，四步法的价值不在于给出唯一答案，而在于把排查范围快速收窄到某一层。

四、分平台操作路径：最短可达

下面给出的是各平台上的常见入口形态。再次强调：菜单文案随版本变化，若你找不到对应项，优先在设置的搜索框（如果客户端提供）里搜「模式」「代理」「连接」等关键词，或直接查看主界面是否有模式切换入口——很多客户端会把最常用的模式开关放在首屏，而不是藏在多级菜单里。入口位置可能不同，但判断逻辑是一致的：先确认接管层是否生效，再讨论规则与协议。

4.1 Android：设置 → 连接相关分组

Android 上的最短路径通常是：打开客户端，进入底部导航的「设置」（或右上角的齿轮图标），在连接、网络或代理相关的分组里找到模式选项。部分版本会把模式切换做成主界面上的一个可点击标签，点一下弹出候选列表。切换完成后，注意观察状态栏是否出现 privacy tool 或代理相关的常驻图标——这是判断接管是否真正生效的最直接信号。若切换后图标迟迟不出现，先断开再重连一次，而不是反复点选项。

4.2 iOS：受系统限制更多

iOS 的路径与 Android 类似，但系统对后台驻留和网络扩展的限制更严。切换模式后，若发现部分应用仍然不走代理，先确认是否在系统设置里为该客户端授予了必要的网络权限；其次注意 iOS 上「按规则分流」的覆盖面通常比桌面端更依赖客户端内置规则，自定义空间较小。一个实用技巧：切换模式后不要立刻下结论，先在浏览器里打开一个已知能反映出口地址的查询页面，确认出口确实变了，再去测试具体应用。

4.3 Windows：偏好设置中的连接分组

桌面端一般从主界面右上角的菜单进入「设置」或「偏好设置」，在连接分组里可以同时看到模式与协议两项。Windows 上的一个常见问题是权限：虚拟网卡形态需要管理员权限，若客户端以普通权限启动，可能出现「模式选了但没生效」的假象。验证方法是打开任务管理器的网络列，或直接在系统适配器列表里查看是否出现了新的虚拟适配器。没有出现，说明接管层没起来，此时应关闭客户端、以管理员身份重新启动，而不是继续在模式选项之间来回切换。

4.4 macOS：留意系统扩展授权

macOS 上的路径与 Windows 接近，但多一道系统级关卡：网络扩展需要用户在「系统设置 → 隐私与安全性」中授权。若授权未完成，客户端界面看起来一切正常，实际流量却完全没被接管。判断方式很简单——打开「活动监视器」的网络标签，或者用系统自带的网络工具查看当前默认路由是否指向了新的接口。这一步在换新机、重装系统后尤其容易遗漏。

五、全部转发模式的代价：什么时候值得，什么时候别碰

全部转发模式的价值在于消除变量。当你不确定问题出在本地网络、运营商、还是目标站点时，把所有流量收进同一条通道，能让「换个环境是否复现」这个判断变得干脆。它也适合需要统一出口身份的场景，比如某些后台系统对登录地与操作地的一致性有要求。这是它值得用的地方。判断标准不是模式本身先不先进，而是当前任务是否真的需要统一出口。

但它不该成为默认状态。原因有三。其一，局域网发现与共享会受影响，表现为找不到网络打印机、投屏设备、NAS 共享目录。其二，本地开发环境容易被牵连，尤其是依赖回环地址或本地域名的项目。其三，某些企业网络会对「全部流量走单一外部通道」这一特征做额外限制，反而让原本可用的服务变得不可用。可复现的验证方法是：在全部转发模式下，依次测试「访问局域网设备」「访问本地服务」「访问外部站点」三类目标；若有任意一类失败，而你并不需要全局一致性，就应当退回按规则分流。

六、按规则分流的边界：它会漏掉什么

按规则分流是日常使用的主力模式，但它的可靠性完全取决于规则表。三类流量最容易被漏掉：一是新建不久或较少人使用的域名，规则库更新存在滞后；二是走非标准端口的服务，部分规则只按域名匹配，端口不在考虑范围内；三是应用内部硬编码了地址、绕过了域名解析的请求。第三类最难排查，因为从浏览器看一切正常，只有那个特定应用出问题。规则库的更新节奏通常跟不上域名变化，这是机制性限制，不是某一次配置失误。

定位方法并不复杂。先在按规则分流下复现问题，再临时切到全部转发，看现象是否消失。消失，说明是规则漏匹配；没消失，说明问题与模式无关，应转向协议或 DNS 层。这个二分动作的价值在于，它能在几分钟内把排查范围砍掉一半，比反复更换节点有效得多。补例外时遵循最小化原则：只针对出问题的那个域名或地址段加规则，不要为了省事把整段地址一次性放行——后者可能在未来引入新的不可预期行为，并且很难回溯是哪一条规则造成的。

七、协议层取舍：自动、TCP 与 UDP 的差别

协议选项通常出现在连接设置的高级区域，表现形式多为「自动 / TCP / UDP」之类的候选。它们不是「哪个更快」的简单排序，而是针对不同网络条件的适配。UDP 在丢包率低、链路稳定的环境下通常延迟表现更好，适合实时性要求高的场景；但在某些限制较严的网络里，UDP 流量可能被优先干扰，此时固定为 TCP 反而更稳。自动选项的意义是让客户端根据握手情况自行选择，代价是你无法确定当前究竟走的哪条路——这在排查阶段是个障碍。自动不是万能，它只是把选择权交给了客户端。

建议的用法是：日常交给自动；一旦进入排查状态，就固定成单一协议，观察现象是否稳定复现。可复现的验证步骤是：分别在两种协议下重复同一个操作（例如打开同一个后台页面并等待完全加载），记录是否出现中断或明显卡顿。经验性观察是，网络环境越复杂（公共 Wi-Fi、酒店网络、跨境链路），协议选择带来的体感差异越明显；而在稳定的家庭宽带下，两者的差别往往被其他因素掩盖。

八、DNS：被忽视的「无法上网」元凶

「连上了但打不开网页」这个现象里，DNS 出问题的比例相当高。典型表现是：聊天类应用能用（它们往往使用长连接和自有解析逻辑），浏览器却转圈；或者首屏能打开、图片和样式加载不出来。原因在于域名解析走了本地运营商，返回的地址与实际出口不匹配，请求绕了远路甚至被丢弃。这类现象之所以迷惑，是因为连接状态看起来完全正常，用户很容易把注意力放在节点上。

验证方法很直接：在切换模式或协议前后，分别查询同一域名的解析结果，观察返回的地址是否变化、是否合理。命令行环境下可以用系统自带的域名查询工具，图形界面下可以借助浏览器开发者工具的网络面板查看请求的实际目标地址。如果发现解析结果长期指向明显不合理的位置，再考虑调整 DNS 相关设置。需要提醒的是，修改 DNS 会同时影响所有应用的解析行为，属于「影响面较大」的操作，改之前先记录原值，出问题能退回去。

九、故障排查：按现象走的四步法

排查的核心原则是「先分层，再定位」，不要在不确定原因的情况下反复更换节点或重装客户端。下面按三种高频现象展开，每种都给出可复现的验证动作。

9.1 现象：显示已连接，但网页打不开

先做最小化验证：切到直连，看同一网页是否可访问。可访问，说明本地网络没问题，问题在客户端的接管或规则；不可访问，说明问题可能根本不在客户端，先检查本地网络本身。接着检查 DNS 层（见上一节），最后才考虑协议与节点。这个顺序能把最常见的两类原因（规则漏匹配、解析异常）优先排除掉。

9.2 现象：部分应用能用，部分不能用

这类现象几乎可以锁定在「接管方式」上。若客户端当前是系统代理形态，那么不读取系统代理的应用天然会被绕过。验证方法：切换到虚拟网卡形态（若客户端提供），或临时切到全部转发，看那个应用是否恢复。恢复即证实判断。需要注意的是，虚拟网卡形态对权限有要求，切换后若未见效，先去确认权限与适配器状态，而非认定功能本身不可用。

9.3 现象：频繁断连或速度骤降

先排除协议因素：固定为单一协议重复测试，观察断连是否仍然出现。再排除规则因素：切到全部转发，看是否依旧。两者都无改善时，才考虑节点与链路质量。部分客户端内置了网络检测或延迟测试入口（位置与名称随版本不同），若你的版本提供，可以用它快速判断节点可达性；若没有，用系统自带的网络诊断工具或直接访问一个稳定的公共页面，同样能达到「链路通不通」的判断目的。

十、验证与观测：三步确认模式确实生效

很多「模式没用」的结论，其实来自「没有验证」。以下三步不依赖任何特定版本的功能，可普遍复现。验证的价值在于把主观感受变成可对照的结果，而不是凭「感觉好像没生效」下判断。

• 看接口：在系统层面确认是否出现了新的网络适配器或隧道接口。没有出现，说明接管层没有起来，此时讨论规则毫无意义。
• 看出口：访问一个能显示当前出口信息的页面，对比切换前后的结果。出口没变，说明流量实际没被接管，或该应用的流量被规则放行了。
• 看解析：查询同一域名在切换前后的解析结果。结果不一致且新结果更合理，说明解析路径也跟着变了，属于预期行为。

三步做完，再回头判断「模式是否适合当前场景」。这个顺序能避免一个常见误区：把「应用不遵守系统代理」误判为「模式失效」，进而做出一堆无效调整。

十一、适用与不适用场景清单

为了让判断更快落地，下面把典型场景列清楚。准入与排除条件都基于前面几节的分析，不涉及任何未公开的功能承诺。这里的分界不是绝对的，关键看当前任务的优先级。

适合用全部转发：需要统一出口身份的后台操作；怀疑本地网络限制、需要做环境对比的诊断场景；短期、明确结束时间的集中作业。

不适合用全部转发：需要访问局域网设备或内网系统的办公环境；本地开发与调试；对网络权限敏感、已安装多个网络工具的设备。

适合用按规则分流：日常办公与内容浏览的混合场景；设备上同时存在国内外站点访问需求；希望减少手工维护成本的长期配置。

不适合用按规则分流：目标站点较新、规则库尚未覆盖；应用内部硬编码地址导致规则无法匹配；需要严格一致出口的合规场景——这类场景应显式选择更严格的接管方式，而不是依赖规则推断。

十二、最佳实践检查表

把上面的结论收敛成一张可执行清单，按顺序过一遍，多数连接类问题都能被提前规避。

1. 先确认权限与系统授权是否到位，再讨论模式与节点。
2. 日常使用按规则分流，把全部转发当作诊断工具，而不是默认状态。
3. 协议保持在自动；进入排查时固定为单一协议，便于对照。
4. 为内网地址段与本地服务保留直连例外，且例外只加必要的、最小范围的条目。
5. 修改 DNS 前记录原值，改完用同一域名做前后对比。
6. 每次只改一个变量，改完立即用「接口—出口—解析」三步验证。
7. 遇到「部分应用不能用」，先判断接管方式，再判断规则。
8. 排查记录写下来：改了什么、观察到了什么、是否可复现。下一次同类问题能省掉大半时间。

十三、常见问题

十四、收尾：把模式当成参数，而不是开关

回到最初的问题——QuickQ 连接设置支持哪些网络模式。更准确的表述是：它提供的是一组可组合的参数，覆盖流量走向、接管方式、协议与解析四个维度，具体呈现的选项名称与数量随平台和版本变化。理解这四层各自的职责，比记住某几个选项名称更有用，因为界面会变，判断逻辑不会变。

如果只带走一句话：先用按规则分流覆盖日常，把全部转发留作诊断，任何调整都以「接口—出口—解析」三步验证收尾。下一步建议你做一件很小的事——花五分钟，在当前的网络环境下把三种模式各切一次，记录下每次的出口与解析结果。这份属于你自己的对照表，比任何通用教程都更贴合你的实际环境，下次遇到「连上了但上不了网」时，它能帮你把排查时间从几小时压到几分钟。