Skip to content
文章 / 1 分钟阅读

Proxifier + SOCKS5：只让你选择的应用通过代理路由

Proxifier 可让你按应用使用 SOCKS5 代理，而非全局使用。如何添加代理、决定 DNS 解析位置、编写行为符合预期的代理化规则，并修复困扰大多数用户的泄漏问题。

大多数代理设置都是全有或全无。要么你更改系统设置，所有流量都走代理；要么你配置单个应用，其他一切都不受影响。Proxifier 处于中间位置：它在套接字层拦截出站连接并应用规则——这个应用使用代理，那个应用直连，这个主机完全阻止。

这使得它天然适合 SOCKS5，因为 SOCKS5 可以承载任何 TCP 流量，而不仅仅是 HTTP。本指南涵盖设置步骤、导致大多数泄漏的 DNS 决策，以及防止你代理本不打算代理的内容的规则。

开始前有一个注意事项：不同 Proxifier 版本和平台之间，菜单名称会略有差异。下面的概念是稳定的，因此如果某个标签不完全匹配，请寻找最接近的等效项。

Proxifier 能提供哪些系统设置无法做到的功能

  • 应用级路由。 让一个浏览器走代理，其他所有内容保持直连。
  • 目标级路由。 将发往特定域名或 IP 范围的流量走代理，其余直连。
  • 协议无关代理。 任何 TCP 应用都可以通过 SOCKS5 代理路由，即使它自身没有代理设置。
  • 链式代理。 先通过一个代理路由，然后再通过另一跳。
  • 流量日志。 你可以准确看到哪个连接去了哪里，这在发生泄漏时非常宝贵。

开始之前：收集代理详细信息

从你的代理提供商处，你需要：

  • 主机名或 IP 地址，以及端口。
  • 协议：SOCKS5。
  • 如果需要身份验证，则提供用户名和密码。
  • 该端点提供的是轮换 IP 还是粘性会话，因为这决定了有状态的多步骤流程是否可行。

提前决定 DNS 是否应在代理处解析。使用 SOCKS5 时，在本机解析主机名是位置泄漏最常见的原因。大多数提供商通过客户端设置或用户名标志来启用远程 DNS。

步骤 1：将 SOCKS5 代理添加到 Proxifier

  1. 打开 Profile 菜单，选择 Proxy Servers。
  2. 点击 Add。
  3. 输入地址和端口，并将协议设置为 SOCKS Version 5。
  4. 如果代理需要身份验证，请启用并输入凭据。
  5. 在基于它构建任何规则之前，使用内置的 Check 按钮确认代理有响应。

如果检查失败，原因几乎总是以下三种之一：端口错误；凭据因包含特殊字符而需要进行 URL 编码；或者提供商将连接限制为白名单 IP 地址。

步骤 2：决定如何处理 DNS

这是大多数人会跳过的设置，也正是悄悄产生泄漏的设置。在名称解析设置中（通常位于 Profile 下的 Name Resolution），你需要在本地解析主机名或在代理处解析之间做出选择。

  • 通过代理解析，当你的目标是隐藏你的真实位置和 DNS 查询时。这是使用 socks5h:// 而不是 socks5:// 在 SOCKS5 中的等效做法。
  • 本地解析，仅当你特别需要本地 DNS 行为时，例如企业网络中的拆分视界（split-horizon）名称。

如果网站看到的地理位置与你的真实位置匹配，而不是与你的代理位置匹配，这就是第一个要检查的设置。

步骤 3：编写代理化规则

规则位于 Profile 下的 Proxification Rules。它们按顺序评估，第一个匹配项生效，因此顺序比任何单个条目都重要。

一个合理的起始结构：

  1. 本地地址直连。 回环地址和你的局域网绝不应走代理。
  2. 代理服务器本身直连。 如果没有这条，某些配置会尝试将代理流量再发回代理。
  3. 对你关心的特定应用使用代理。 每个可执行文件一条规则，动作设置为你自己的 SOCKS5 代理。
  4. 其他所有内容直连或阻止。 有意识地选择你希望默认采用两者中的哪一个。

每条规则可以匹配：

  • 应用程序——可执行文件名称或路径。
  • 目标主机——域名、通配符或 IP 范围。
  • 目标端口——例如仅将端口 443 通过代理发送时很有用。

保持列表简短。当出现问题时，包含三十个相互重叠条目的规则集根本无法推理。

步骤 4：验证流量确实流向你认为的位置

验证分为三部分：

  1. 在流量日志中，确认你刚建立的连接归属于 SOCKS5 代理，而不是 Direct。
  2. 从应用程序中，检查公共 IP 检查页面报告的 IP。
  3. 从命令行中，将直接请求与通过代理的请求进行比较：
# 直连
curl -s https://api.ipify.org; echo

# 通过 SOCKS5 代理并使用远程 DNS 解析
curl -s --proxy socks5h://user:[email protected]:1080 https://api.ipify.org; echo

如果这两个命令的结果不一致，说明你的规则并没有匹配到你认为它匹配的应用程序。这通常是顺序问题，或者规则匹配的是启动器，而不是实际进行网络连接的进程。

常见的 Proxifier + SOCKS5 问题

  • 规则匹配的是启动器，而不是进程。 浏览器和运行时通常会生成一个单独的子进程来打开套接字。应匹配实际建立连接的进程。
  • DNS 泄漏。 上面已讨论过，但它仍然是“我的 IP 变了，可网站仍然知道我在哪里”的第一大原因。
  • 代理客户端本身被代理了。 使用过宽泛的应用规则很容易造成循环。
  • 与 VPN 或杀毒软件过滤驱动冲突。 分层网络拦截很脆弱。如果 VPN 客户端正在运行，请先单独测试 Proxifier。
  • 沙盒化应用程序。 在受限沙盒中运行的应用，可能无法通过与普通桌面软件相同的机制被拦截。

什么时候你根本不需要 Proxifier

如果只有浏览器需要代理，浏览器级配置更简单。如果你需要为命令行工具使用 SOCKS5，SSH 动态转发结合 proxychains 之类的包装器也能起到类似作用。如果你希望设备上的每个应用都被路由，且不需要按应用规则，VPN 是更干净的工具。Proxifier 特别适用于需求是选择性的、按应用路由的场景。

要点总结

先添加 SOCKS5 代理并确认其有响应，有意识地决定 DNS 是在本地解析还是在代理处解析，然后保持规则列表简短且有序，使第一个匹配项始终是你所期望的。通过流量日志和 IP 检查进行验证——并将两者之间的任何不一致视为规则匹配错误，而不是代理问题。