QuickQ连接失败时如何检查代理设置？

功能定位与边界：代理设置在 QuickQ 排错中的位置

QuickQ连接失败时，代理设置是最值得先查的一层，但它不是唯一一层。把连接链路拆成“物理网络—DNS—TCP—本地代理端口—TLS—应用认证”六段，代理设置主要影响第三到第五段。这样拆的好处是，你能用一条命令判断问题是否还在本地，而不是在“重装—换节点—再重装”之间循环；换句话说，代理设置更像链路中间的可观测层，先看它，是为了把问题从“感觉连不上”收窄到可验证的环节。

代理设置在这里有两层含义：一层是操作系统里的系统代理，另一层是 QuickQ 客户端内的连接或代理模式。前者决定其他应用是否把流量交给本地端口，后者决定 QuickQ 自己如何接管流量。两者混在一起改，很容易出现“浏览器好了、QuickQ 还失败”的假象。经验性观察是，先把系统代理恢复为“无”，再单独验证客户端，定位速度通常更快，因为这时你面对的是一个变量更少的基线，而不是两组设置相互干扰的结果。

边界也要说清楚：如果公司网络强制使用 MDM 或组策略下发代理，个人端关闭系统代理可能被立即改回；这时不要反复对抗策略，应记录策略值并联系管理员。若设备涉及金融、医疗等合规场景，也不建议为了排错长期关闭 TLS 校验或安装来源不明的根证书。把“能改什么、不能改什么”先划出来，后面的分诊才不会变成无效尝试。

60 秒分诊：用现象把问题缩小到三层

先不要改任何设置，做一次最小复现：断开并重新连接当前 Wi-Fi，关闭其他代理或 privacy tool 类软件，启动 QuickQ，观察失败发生在“认证前”还是“认证后”。认证前通常表现为一直转圈、提示无法连接服务器；认证后则可能显示已连接但网页打不开。两类现象对应的检查顺序不同，这一步的价值就在于先把“认证前”和“认证后”分开，避免一上来就同时动代理、DNS 和客户端模式。

可以用三个动作建立基线：第一，用浏览器访问一个常用 HTTPS 站点，判断基础网络是否通；第二，在 QuickQ 内切换一次节点或协议（若界面提供），判断是否与特定线路有关；第三，用系统命令测试本地代理端口是否在监听。三步都不需要卸载软件，却能排除大部分“设置被残留”的问题。这里的关键不是把三步做成清单，而是让每步都留下一个可对照的结果：能通、不能通、只在某条线路下失败。

• 只有浏览器失败、其他应用正常：优先查系统代理和浏览器自身代理扩展。
• 只有 QuickQ 失败、浏览器正常：优先查客户端内代理模式、端口占用和防火墙。
• 所有应用都失败：先查物理网络、DNS 和系统代理残留，再查账号状态。

上面三类现象可以理解为三个互斥的排查入口，先选一个最贴近的入口，不要同时展开。这里的“60 秒”是操作节奏，不是性能承诺。实际耗时取决于系统响应和你是否熟悉路径。若三次复现都在同一阶段失败，就应停止盲目切换，转入下一节的分层检查。

平台差异：系统代理的最短检查路径

Windows 11/10 的最短路径是“设置 > 网络和 Internet > 代理”，先看“自动检测设置”和“手动设置代理”是否被打开。若手动代理指向 127.0.0.1 的某个端口，而 QuickQ 已退出，浏览器就会整体报错。此时把手动代理改为关闭，保存后再测。需要提醒的是，WinHTTP 代理与用户级代理并不完全等同，某些系统组件走的是另一套配置，排错时不能只看一个开关；如果浏览器恢复而系统组件仍异常，就要意识到这里可能不是同一个代理入口。

macOS 13 及更新系统在“系统设置 > 网络 > 选择当前服务 > 详细信息 > 代理”；旧版在“系统偏好设置 > 网络 > 高级 > 代理”。这里要逐项看网页代理、安全网页代理、SOCKS 代理和自动代理配置，任何一项残留都可能造成分流异常。多个网络服务（Wi-Fi、USB 网卡）分别保存配置，切换网络后要重新确认当前服务，否则你看到的“已关闭”可能只对上一个网络服务生效。

Android 的路径因厂商而异，常见入口是“设置 > 网络和互联网 > 互联网 > 当前 Wi-Fi 右侧齿轮 > 修改网络 > 高级选项 > 代理”。它只对当前 Wi-Fi 生效，移动数据不走这一项。iOS 在“设置 > 无线局域网 > 当前 Wi-Fi 右侧信息按钮 > 配置代理”，可选关闭、手动、自动。手动代理关闭后仍失败，下一步应查客户端内设置，而不是继续在 Wi-Fi 里打转；平台路径只负责把系统层排除干净，不能替代对客户端端口和模式的验证。

提示：QuickQ 客户端内的设置入口在不同平台和版本中可能命名为“设置”“首选项”“网络”或“连接”。截至当前的最新版本，具体文案仍以你安装的界面为准；本文只给出检查逻辑，不把某一版菜单名当作永久路径。

应用内代理模式：全局、规则、PAC、TUN 的取舍

不少代理类客户端会提供全局、规则、PAC、TUN 等模式。全局模式把所有流量交给代理，排错时最容易判断“是不是代理本身有问题”，但代价是本地服务、内网域名和更新流量也可能被绕远。规则模式按域名或 IP 分流，日常开销更低，但规则写错时会出现“主站能开、登录接口失败”的割裂现象。PAC 依赖一个自动配置脚本，脚本不可达时浏览器可能直接走直连或全部失败。TUN 通过虚拟网卡接管流量，兼容性较好，但可能与其他 privacy tool、杀毒软件的驱动冲突。理解这些差异之后，再看 QuickQ 的连接失败，就不会把所有模式都当成同一种“开关”。

如果你只是要验证 QuickQ 的连接能力，建议先用“全局”或“直连对比”做一次 A/B：先记录当前模式，切到全局，重连，打开一个 HTTPS 站点；再切回原模式复测。两次结果不同，说明问题在分流规则，而不在账号或线路。这个做法成本低，但要注意每次只改一个变量，否则无法归因；示例：先只切模式、不动 DNS，复测后再决定是否检查规则。

何时不该用全局：公司内网办公、需要访问本地打印或数据库、使用按流量计费的移动网络时，长期全局会增加不必要的转发和流量成本。何时不该用 PAC：PAC 文件来自不明地址、脚本内容无法审阅、或组织禁止外部脚本时。若 QuickQ 当前版本没有这些模式选项，就跳过本节，重点检查系统代理、端口与防火墙，不要为了“凑步骤”去改不存在的开关；这也是排错时常见的误区——把通用客户端的模式清单误当成当前界面的必备项。

版本差异与迁移：升级后先复核哪几项

截至当前的最新版本，桌面端与移动端的设置入口并不完全一致；旧版本可能把网络选项放在主界面侧栏，新版本可能收进设置页。升级后不要假设旧路径仍然有效，先按“系统代理—客户端模式—端口—防火墙”四项复核。经验性观察是，升级后最常见的问题是旧版留下的系统代理没有被新版本正确接管，表现为浏览器能开、QuickQ 却提示连接失败；路径变化本身不是故障，迁移遗留的配置才是需要优先处理的变量。

迁移时建议先做记录：把系统代理的原值截图或抄下来，把 QuickQ 内当前模式、端口（若界面显示）、分流规则名称记下来。若客户端提供配置导出或导入，先导出备份；若不提供，就用截图和文字记录代替。然后按“先直连、后代理”的顺序恢复：先确认不开代理时基础网络正常，再开启 QuickQ，最后逐项打开分流或证书相关选项。这个顺序能让你在每一步都知道“变化来自哪里”，而不是一次改完再回头猜。

回退方案也要提前想好：保留旧版安装包并不等于应该长期使用旧版，安全更新同样重要。更稳妥的回退是恢复系统代理原值、关闭新增的证书信任、把客户端模式改回默认，再重新登录。若升级后连续多次复现失败，且换网络、换账号均无效，再考虑通过官方渠道反馈，而不是从第三方站点下载修改版；这样既保留可回退路径，也避免把版本问题扩大成安全问题。

兼容性表：不同平台与网络环境的检查重点

下表把平台入口和常见坑放在一起，便于快速对照。表中的“应用内检查点”只描述检查逻辑，不绑定某一版菜单名称；实际界面以你安装的版本为准。它更适合当作对照卡，而不是逐项打勾的清单，因为不同平台的失败现象往往比菜单路径更能决定下一步。

从表中可以看出，Windows 和 macOS 的排错重点在“系统代理是否残留”，Android 和 iOS 的重点在“当前 Wi-Fi 的代理配置是否只影响局部”。如果同一账号在手机能连、电脑不能连，优先怀疑电脑上的系统代理或安全软件，而不是账号本身。反之，所有设备都失败，才应把注意力转向账号状态、订阅有效期或线路；表中的平台差异只是帮你决定先看哪一层，不是对故障原因的最终判决。

深入检查一：端口监听、进程与防火墙

代理设置正确但连接失败，常见原因是本地端口没有真正监听。先记下 QuickQ 界面显示的本地代理端口（若没有显示，可查看客户端日志或网络设置页；不同版本可能不同），再在系统里验证。Windows 可用 PowerShell 执行 Test-NetConnection 127.0.0.1 -Port 端口号，预期返回 TcpTestSucceeded : True；若为 False，说明端口未监听或被拦截。也可以用 netstat -ano | findstr :端口号 查看占用进程。这里的顺序很重要：先确认“有没有在听”，再讨论“听得对不对”。

macOS 可用 lsof -nP -iTCP:端口号 -sTCP:LISTEN 查看监听，用 curl -I -x http://127.0.0.1:端口号 https://example.com 测试 HTTP 代理链路。若 curl 返回“Connection refused”，优先怀疑客户端未启动代理监听或端口写错；若返回证书错误，再查 TLS 与证书信任。测试命令只是诊断，不要把端口号硬编码到长期脚本里；排错结束后，保留一次输出记录即可。

防火墙与安全软件要按“最小权限”处理：只允许 QuickQ 的可执行文件通过，而不是关闭整个防火墙；只放行必要的本地回环端口，而不是开放整个网段。Windows 可在“控制面板 > 系统和安全 > Windows Defender 防火墙 > 允许应用通过防火墙”中核对；macOS 在“系统设置 > 网络 > 防火墙”中查看。第三方杀软可能单独拦截本地代理，需要在其日志中确认是否出现 QuickQ 相关拦截记录；如果有记录，优先调整规则而不是直接停用防护。

深入检查二：DNS、分流规则与证书

DNS 问题常表现为“代理端口通，但域名解析失败”。用 nslookup example.com 或 dig example.com 对比直连与代理下的解析结果；如果直连返回正常、代理下超时，可能是 DNS 请求没有走预期通道，或被分流规则误判。此时先切回默认 DNS 或系统 DNS，再复测；不要同时改 DNS 和代理模式，否则无法判断是哪一项生效。DNS、规则与证书三类问题的共同点，是端口看起来正常、失败却发生在应用层，所以更要用对比结果说话。

分流规则的坑更隐蔽：公司内网域名、登录回调域名、支付回调域名被错误地送入代理，会出现“首页能开、登录失败”。可复现的验证方法是只针对失败域名做一次直连对比：在规则中临时把该域名设为直连，重连后复测；若恢复，说明规则需要修正。经验性观察是，规则越多，首次连接建立越可能变慢，但具体程度因设备和规则数量而异，不能给出统一阈值；因此规则修正后也要复测一次日常打开速度，而不是只看登录是否恢复。

证书问题通常出现在启用了 HTTPS 解密或安装了中间证书的场景。若浏览器提示证书不受信任，而关闭解密后恢复，就不要继续在生产环境强行解密。检查证书信任时，优先看系统证书管理界面和应用内是否明确提示；不要从不明来源下载根证书。对于无法确认证书来源的公共 Wi-Fi，宁可放弃解密，也不要把“忽略证书错误”当作常规排错手段；这类操作一旦形成习惯，后续很难区分是网络问题还是信任链被人为放宽。

典型故障案例：从现象到处置

案例一：办公室 Wi-Fi 下浏览器正常，QuickQ 一直提示连接失败；回家后正常。检查发现办公室系统代理被组策略设置为一个已下线的地址。处置不是反复重装，而是记录组策略值、联系管理员，并在个人热点下验证客户端本身是否正常。这个案例的边界是：公司设备可能不允许个人修改代理，强行修改会影响合规；它对应的根因是“策略下发”，不是客户端损坏。

案例二：用户把系统代理手动设为 127.0.0.1 的某端口，之后直接退出 QuickQ，浏览器全部报错。现象看起来像“QuickQ 把网络弄坏了”，实际是系统代理残留。处置是把系统代理改为关闭，再启动客户端让客户端自己接管；若客户端提供“退出时恢复系统代理”的选项，应确认其生效。验证方法是退出客户端后刷新浏览器，预期不再报代理连接错误；这个案例说明，退出顺序和残留状态同样会影响现象判断。

案例三：只有某个登录接口失败，首页和静态资源正常。把该接口域名临时设为直连后恢复，说明分流规则误杀。处置是修正规则并记录变更，而不是关闭全局代理。这里的取舍是：规则模式日常开销更低，但维护成本更高；如果不想维护规则，可以选择更简单的模式，同时接受全局转发带来的额外开销。三个案例分别落在策略、残留和规则三类根因上，处理动作不同，但共同点都是先记录再变更。

风险与边界：哪些操作不该做

第一，不要为了排错长期关闭防火墙或杀毒软件。正确做法是加白名单并观察日志，排错结束后恢复原策略。第二，不要安装来源不明的根证书，也不要在公共电脑上保持“信任所有证书”。第三，不要从第三方站点下载修改版客户端；修改版可能篡改代理设置，反而让问题更难复现。第四，涉及公司数据或合规业务时，先确认组织政策，再决定是否使用个人代理。把这四条当作硬边界，能避免“排错动作本身制造新故障”。

还有一个容易忽略的边界：系统代理只影响遵循系统代理的应用。命令行工具、部分开发工具和游戏可能不读取系统代理，需要单独配置环境变量或应用内代理。若你用浏览器测试正常，就断言“代理设置没问题”，可能会漏掉这些应用。验证时应尽量用与故障应用同类的客户端做对比，这样得到的结论才更接近真实使用路径。

适用与不适用场景清单

适用场景：个人设备、你可以修改网络设置、故障可稳定复现、能承担十到二十分钟的排错时间。此时按“系统代理—端口—DNS 或规则—证书”的顺序检查，收益最高。若你只是偶尔连接失败，先做一次重连和换网络，不必展开全部步骤；判断标准不是“能不能连”，而是“失败是否可复现、是否在可控环境”。

不适用场景：公司管控设备且禁止修改代理、金融或医疗等强合规环境、无法确认代理或证书来源、公共电脑。此时更合适的动作是联系管理员或放弃在该设备上排错，而不是绕过策略。对于“是否值得继续查”的判断，可以用一个简单规则：如果换网络、换设备后仍失败，且失败阶段一致，就值得深入；如果每次现象都不同，先建立可复现步骤，再谈设置。这个规则的作用是防止把偶发现象误判成稳定故障。

最佳实践检查表与收尾

把下面的检查表当作决策规则，而不是一次性清单。每次只改一个变量，改完立即复测并记录结果；失败时优先回退到上一个可用状态。这样即使问题没有立刻解决，你也能留下可复现的证据，避免下次从零开始。

1. 记录系统代理原值，关闭残留的手动代理和 PAC。
2. 退出其他 privacy tool 或代理类软件，避免端口和虚拟网卡冲突。
3. 启动 QuickQ，确认客户端内模式与端口，先用直连对比。
4. 用系统命令测试本地端口是否监听，再用 curl 测试代理链路。
5. 检查防火墙与安全软件日志，按最小权限加白名单。
6. 对比 DNS 解析结果，临时把失败域名设为直连验证规则。
7. 只在确认必要时处理证书，不长期忽略证书错误。
8. 升级后复核四项：系统代理、客户端模式、端口、防火墙。

收尾时给一个明确结论：QuickQ连接失败时，代理设置应作为第一层排查，但要用“分层验证”代替“反复重装”。先恢复系统代理到干净状态，再验证客户端端口与模式，最后才动 DNS、规则和证书。下一步建议你保存一份自己的基线记录，包括当前网络、系统代理状态、客户端模式和测试命令输出；下次复现时，先对比基线，再决定是否修改设置。未来版本若调整菜单命名或入口位置，这套“先系统层、再客户端层、最后应用层”的检查逻辑仍可复用，届时以你安装界面的实际文案为准。

FAQ：常见问题