QuickQ怎么设置代理自动切换规则

2026年6月18日 QuickQ 团队

QuickQ 的代理自动切换规则可以按域名、IP 段、应用、Wi‑Fi 名称或时间段自动判断流量该走代理还是直连。先理解“匹配条件—动作—优先级—生效范围”这四个要素，按顺序建立规则并逐条测试，必要时用 PAC 脚本或正则加强灵活性；注意 iOS 与 Android 在系统层面的差异、DNS 泄露与本地网段例外，最后启用日志与检测，反复校准即可。

QuickQ怎么设置代理自动切换规则

为什么要用自动切换规则？先把概念搞清楚（像给朋友解释）

想象你家门口有两个路口：一条经过隐蔽的快速隧道（走代理），另一条是通向本地小区的巷子（直连）。并不是每次出门都要进隧道——比如访问家里的 NAS、打印机或国内银行网站时，走巷子更快也更稳定。自动切换规则就是告诉 QuickQ：哪些流量必须走隧道，哪些可以直连，怎么判定优先级，出问题怎么退回以及在什么场景下启用哪套规则。

四大要素：匹配条件、动作、优先级与生效范围

  • 匹配条件（Match）：决定某个请求是否命中规则。常见的有域名（domain）、域名后缀（domain-suffix）、域名关键字（domain-keyword）、IP 段（CIDR）、正则、应用程序包名、Wi‑Fi 名称（SSID）、网络类型（蜂窝/Wi‑Fi）和时间段。
  • 动作（Action）：命中规则后执行的操作，通常是“代理（使用指定节点）”、“直连（不走代理）”、“绕过本地（直连但保持本地子网例外）”或“拒绝/阻断”。
  • 优先级（Priority）：规则是按顺序匹配的，先匹配到的生效。你可以用顶部到底部的顺序或显式优先级数字来控制。
  • 生效范围（Scope）：规则是否限定某些设备、某些应用或仅在特定网络（如公司 Wi‑Fi）下生效。

举个快速比喻

把规则看作交通指示牌：牌子上写着“去机场的车请走高速”，这是域名或 IP 的匹配条件；写着“本地快递请走小路”的则是直连规则。路牌靠前的更重要，摆在路口前的先被看到。

在 QuickQ 中设置自动切换规则：按步骤来（实践指南）

下面按实际操作顺序写，兼顾 Android/iOS/macOS/Windows 的共性与差异。先说通用步骤，后面再展开每一项的细节与实例。

通用设置流程（适用于大多数平台）

  • 打开 QuickQ，进入“设置”（Settings）或“网络/代理”部分。
  • 新建规则集合（可命名为“默认规则”、“流媒体优化”等）。
  • 按顺序新增规则：填写匹配条件、选择动作（并指定节点或直连）、可选设置生效设备或应用。
  • 设置默认策略（Default policy），当没有规则命中时采用全局代理、全局直连或智能模式。
  • 保存并启用规则。建议先启用“测试/日志”模式，观察命中情况，并逐条调整。

详细字段解释与填写建议

  • 规则名称：清晰简短，例如“绕过局域网”、“只代理外服域名”。
  • 匹配类型：
    • domain：完全匹配，如example.com
    • domain-suffix：后缀匹配，如 .google.com 会匹配 accounts.google.com
    • domain-keyword：关键字匹配，例：包含 “google” 的域名
    • ip-cidr：IP 段，例如 192.168.1.0/24 或 203.0.113.0/24
    • regexp：正则表达式，用于复杂匹配
    • app：按应用包名或进程名分流（某些平台受限）
  • 动作：选择具体代理节点（如香港节点）、直连或拒绝；有些平台支持“负载均衡”或“备用节点”选项。
  • 优先级/顺序：把例外规则和本地设备绕过规则放在最前面，常用策略放前，通配或默认策略放后。
  • 生效范围：如果 QuickQ 支持，限定规则只对某些设备或仅在特定 Wi‑Fi 下生效（如公共 Wi‑Fi 强制代理）。

常见场景与示例规则集（直接拿来用）

下面给出几个典型场景和对应规则示例，复制到 QuickQ 新建规则时可以按思路填写（示例语法基于多数规则引擎通用写法）。

场景一：只把国外网站走代理，国内网站直连

  • 规则1（本地/内网绕过）：ip-cidr:10.0.0.0/8 → 直连
  • 规则2（本地/内网绕过）：ip-cidr:192.168.0.0/16 → 直连
  • 规则3（国内域名优先直连）：domain-suffix:cn → 直连
  • 规则4（国外流量代理）：default → 代理（指定节点）

场景二：仅对某些应用走代理（比如浏览器和 torrent 客户端）

  • 规则1：app:com.android.chrome → 代理（节点A）
  • 规则2：app:org.qbittorrent → 代理（节点B）
  • 规则3：default → 直连

注意：iOS 对应用级别分流有系统限制，通常通过 VPN 扩展 API 或 MDM 才能实现完整分流。

场景三：公共 Wi‑Fi 下强制全部走代理，家庭网络则智能切换

  • 规则1：ssid:CoffeeShopWiFi → 代理（优先节点）
  • 规则2：default → 按域名规则智能切换

正则、域名通配与常见写法误区

规则越灵活，写法越容易出错。下面列出常用写法与坑：

  • 域名写法：域名后缀写法通常是“domain-suffix:example.com”，不要写成“*.example.com”。
  • 关键字：domain-keyword:google 会匹配所有包含 google 的域名，但也可能误伤子域名或广告域。
  • 正则：regexp:^.*\\.example\\.com$（在正则里点要转义）。正则性能开销大，尽量少用在高频规则里。
  • CIDR：192.168.1.0/24 是正确写法；别把单个 IP 写成 192.168.1.0/24 的错误段。
  • 顺序决定生死：把更具体的匹配放前面，通配放后。

PAC 脚本：当 GUI 不够用时（给进阶用户）

PAC（Proxy Auto-Config）是基于 JavaScript 的代理判断脚本，适合复杂逻辑：按 URL、主机、端口、源地址等自定义路由。QuickQ 若支持自定义 PAC，可以把复杂条件写进脚本。

常见 PAC 片段 
function FindProxyForURL(url, host) {
  // 本地地址直连
  if (isPlainHostName(host) || shExpMatch(host, "*.local") || shExpMatch(host, "192.168.*")) {
    return "DIRECT";
  }
  // 公司内网 IP 直连
  if (isInNet(host, "10.0.0.0", "255.0.0.0")) {
    return "DIRECT";
  }
  // 流媒体走指定代理
  if (dnsDomainIs(host, ".netflix.com") || dnsDomainIs(host, ".hulu.com")) {
    return "PROXY hk-node.example:1080";
  }
  // 默认走代理
  return "PROXY us-node.example:1080; DIRECT";
}

上面示例展示了“本地直连 → 流媒体走特定节点 → 其余优先走代理并备选直连”的策略。PAC 可读 DNS 名、判断端口、检查 IP 段，非常灵活，但调试和维护成本高。

测试与排查：规则写完后怎么验证有效性

  • 开启 QuickQ 的“规则日志”或“调试模式”，查看每个请求命中哪条规则。
  • 用浏览器访问 whatismyip 或者通过命令行 curl –interface 等命令检查出口 IP。
  • 做 DNS 泄露测试（使用 DoH/DoT 设置），确保查询也按预期通过代理或直连。
  • 测试常见场景：访问国内站点、访问目标流媒体、访问局域网设备（打印机、NAS）等，确认是否按规则走流量。
  • 遇到不生效时，先把所有规则按优先级打印一遍，注意通配规则是否拦截了更具体的匹配。

平台差异与注意事项（别到处套用同一配置）

  • Android：通常支持应用级分流、PAC 和域名/IP 分流，权限较灵活；需要注意后台限制和电池优化可能影响 VPN 稳定性。
  • iOS：受系统限制，应用分流和低层分流能力有限，使用 NEProxy 或配置描述文件更稳定，但需要额外权限。
  • Windows/macOS：桌面端支持最全，支持 PAC、路由表修改和更细粒度的分流，建议在桌面端做复杂规则测试。
  • Linux（Ubuntu）：可通过系统路由、iptables/ nftables 精细控制，但对普通用户有一定门槛。

高级优化与常见策略

  • 分节点策略：不同类型流量走不同节点（流媒体走节点A，游戏走低延迟节点）。
  • 备用/回退：当主代理不可用时自动切换到备用节点，避免中断。
  • 基于网络自动切换：在办公室/家庭/公共热点下自动启用不同规则集。
  • 最小化 DNS 泄露：启用 DNS 代理或使用 DoH/DoT，确保 DNS 查询也走期望路径。
  • 定期更新 GeoIP 数据库：如果使用基于国家/地区的规则，需保证 GeoIP 数据库及时更新。

常见错误与排错清单（快照清单，方便查）

  • 规则无效：检查顺序，是否被之前的通配规则拦截。
  • DNS 泄露：确认 DNS 是否走代理或指向可信 DoH/DoT。
  • 局域网设备不可访问：确保有“绕过本地子网”的直连规则在最前。
  • 应用分流不起作用：平台可能不支持按应用分流，或包名写错。
  • 性能下降：过多正则或复杂 PAC 会增加延迟，优先使用域名后缀和 CIDR。

一个推荐的起始规则模板（可直接导入或参考）

顺序 匹配 动作 说明
1 ip-cidr:10.0.0.0/8 DIRECT 本地网段绕过
2 ip-cidr:192.168.0.0/16 DIRECT 家庭/办公局域网
3 domain-suffix:cn DIRECT 国内域名直连（可按需细化）
4 app:com.example.browser PROXY 节点A 浏览器走代理
5 default PROXY 节点B; DIRECT 默认优先代理，失败回退直连

最后的一些实用小技巧

  • 把“本地/内网绕过”规则放在最前面，避免不必要走代理。
  • 为关键服务（银行、支付）专门设置直连规则，避免被代理节点误判或触发风控。
  • 使用日志和命中统计来优化规则，按访问量调整顺序，常访问的具体规则放前。
  • 如果不确定，先在小范围（个人设备）做灰度测试再全量启用。
  • 保持规则集简单易读：复杂的正则和 PAC 脚本只在必要时使用并加注释。

写到这里我想着把常见问题和具体样例都列一遍，可能还有一些平台差异或第三方工具能配合 QuickQ 做更复杂的策略（像 iptables、路由表或系统级路由管理器），你如果想要我把某个平台的具体界面步骤、PAC 定制模板或常见问题单独展开讲，我可以继续把那部分补上，顺手再把几个实际规则文件示例给你。