在之前的文章SSH隧道:访问翻墙服务器的临时性手段 的时候介绍了一种使用 SSH 隧道进行端口映射，进而进行手动的流量混淆的技术。就稳定性来说这个方案是经受了考验的。在过去几年里，无论任何时候 SSH 隧道都是能够提供稳定可靠的链接的。不过，SSH 隧道的性能是一个问题。根据 Stackoverflow 上的 这个问题下的回答 来说：“当你通过TCP隧道传输TCP时，性能问题就会出现，因为您有两个层执行自适应纠正”。在这篇文章里面我介绍一个较新的方案。

1 简介

新的方案设计一个新的工具：spiped(github)。spiped是一种安全的、轻量级的加密通信工具，可用于在不安全的网络中传输敏感数据。它的设计目标是提供简单、易于配置和使用的加密通信，而不需要复杂的密钥管理或公钥基础设施。spiped使用对称密钥加密算法，可以在客户端和服务器之间建立加密通道。它可以用于保护各种类型的数据流，包括SSH、Telnet、HTTP和SMTP等协议。spiped的另一个优点是它可以在不同的平台上使用，包括Linux、FreeBSD、OpenBSD和Windows等操作系统。

2 使用方法

spiped 的使用非常简单。在 Ubuntu 上可以通过 apt 来安装。也可以自行编译。在完成安装以后，我们首先进入服务端，运行下面的命令生成一个秘钥：

1

dd if=/dev/urandom bs=32 count=1 of=keyfile

其中 keyfile 是生成的秘钥文件，注意将其保管到合适的位置。然后用下面的服务启动 spiped 服务端服务：

1

spiped -d -s '[0.0.0.0]:8025' -t '[127.0.0.1]:25' -k /path/to/keyfile

其中 -s 后的地址是服务端的监听地址，-t 的转发的目标地址，-d 表示将加密的流量从 -s 后的地址解密后发往 -t 后面的地址。这里我们可以填写 Shadowsocks 服务监听的地址。注意 Host 可以保持成 127.0.0.1 的形式。这样，我们可以在防火墙中把 Shadowssocks 的公网监听端口关闭，仅允许从加密隧道访问，这样可以提升安全性。

上面的命令在输入后会自动进入 Daemon 模式运行。

然后我们来到客户端（一般是跳板机），将服务端生成的秘钥文件下载到客户端，运行

1

spiped -e -s '[127.0.0.1]:25' -t $SERVERNAME:8025 -k /path/to/keyfile

其中 $SERVERNAME 是服务端的 IP 地址。注意用 [] 包裹的形式来填写。如果这里说的客户端也是 Shadowsocks 的机器，那么这里的源地址（-s 后的地址）可以写 127.0.0.1，但是如果是跳板机，那么应该写成 0.0.0.0。

客户端的程序也是会自动进入 Daemon 模式运行。

完成设置之后，访问客户端（跳板机）的 25 端口就相当于直接访问服务器的 25 端口。

3 后记

请注意，spiped：

• 需要一个强密钥文件：通过-k选项指定的文件应该具有至少256位的熵。（dd if=/dev/urandom bs=32 count=1是你的好朋友。）
• 需要来自/dev/urandom的强熵。（确保您的内核的随机数生成器在引导时被种子化！）
• 不提供任何防止通过数据包计时泄露信息的保护：在spiped上运行telnet会保护密码不会被直接从网络中读取，但不会掩盖输入节奏。
• 对于交互式会话，可以显着增加带宽使用：它以1024字节的数据包发送数据，并将较小的消息填充到此长度，因此如果不能与相邻字节合并，则1字节的写操作可能会扩展到1024字节。
• 使用对称密钥——因此，任何可以连接到spiped“服务器”的人也可以冒充它。

Proxifier 是一款网络工具软件，可以帮助用户通过代理服务器进行网络访问，实现匿名化、翻墙、加速等功能。支持多种代理协议，规则管理，流量监控和日志记录等功能，提高网络连接的灵活性和智能化。注意 Proxifier 本身并不是一个代理软件，也不是一个 VPN 软件，其作用是控制其他其他软件访问代理的方式。

上一篇文章我提到了可以试用 Proxifier 来解决通过 Shadowsocks 代理访问呢 ChatGPT 频繁出现 Something Went Wrong 的问题，在本文中我们来展开讲一下具体的做法。

1 准备工作

1.1 软件下载

Proxifier 的官方网站是 https://www.proxifier.com/，其正版价格较贵，约 40 美元。不过，较早的 2.x 版本存在破解版。读者可以根据自己的经济状况来选择。

1.2 代理准备

如同开头提到，Proxifer 本身不是一个代理程序，读者应该自己提前准备好代理。这些代理中，无论是 Shadowsocks、V2Ray 还是其他常见的代理程序，都会在客户端本地重建一个 Socks5 代理，这一般都可以在代理客户端程序的配置或者服务器设置中看到。下图给出的是 Shadowsocks-NG 客户端在 macOS 中的系统配置，可以看到程序在本地 (localhost) 的 1086 端口创建了一个 Socks5 代理。

这个代理会被进一步转成 http 代理，从而被浏览器使用，这个转换过程是导致 ChatGPT 链接不稳定的元凶。接下来我们要使用 Proxifier 让 ChatGPT 直接使用 Socks5 代理。

2 设置 Proxifier

2.1 添加代理

我们以知乎上这篇文章为范本简要讲一下设置过程。首先我们需要将现有代理软件提供的 Socks5 服务告知 Proxifier，这通过添加代理服务器实现。

注意一般各种代理软件在本地创建的代理都是无需验证的，我们可以取消验证启用。输入设置之后，可以点击检查确认设置是否正确。

3 设置规则

为了让 ChatGPT 的访问能够通过 Proxifier 访问代理，我们需要配置 Proxifier 的代理规则。

添加代理规则的页面如下：

我们有两种方法引导 ChatGPT 的网络访问：

1. 我们可以选择下载 ChatGPT Desktop 客户端，然后通过代理规则中应用程序过滤规则找到 ChatGPT 程序，然后让目标主机为空（这意味着所有的目标主机都会服从本规则）；
2. 将应用程序部分置空，然后在目标主机中填入 ChatGPT 访问的域名。经过我的试验发现，填入 chat.openai.com; challenges.cloudflare.com; *.openai.com; 即可。

事实上，因为 Proxifier 能够全局性地处理所有网络访问，因此，第二种方法对于使用 ChatGPT Desktop 的用户来说同样有效。下图是完整代理规则。

至此我们就完成了设置，你可能需要重启浏览器才能能让 Proxifier 成功地引导 ChatGPT 的流量。

由于国情原因我们使用使用 ChatGPT 需要使用各种形式的代理，这时我们肯能会发现在与 ChatGPT 对话的过程中可能会出现下面的错误：

这种错误一般在我们再让网页空闲一段时间（通常是一分钟）后再次提问时出现。当然，去 OpenAI 的帮助中心是不会搜到什么有用的信息的。如果你去检索这个问题，你能得到的最好答案是在出现这个页面之后刷新页面，然后回到对话窗口继续对话即可。但是刷新后如果再次出现空闲窗口的情况，这个问题会反复出现，因此你在对话中就不得不反复地刷新页面，再加上每次页面重载你都需要去勾选 Cloudflare 的机器人验证框，这就会极大程度上拖慢我们的速度，影响产品体验。

这个问题是否可能是由于我翻墙访问导致的呢？我使用的翻墙软件是 Shadowsocks，经过一番搜索，一个 Github Issue 的讨论给了我灵感。

尽管讨论的题目和 ChatGPT 没有直接关系，但是这个回复提到，Shadowsocks 在构建代理管道时，会在客户端使用 Privoxy 来讲 Socks5 代理转换成 http 代理，进而被浏览器使用。Privoxy 的配置中包含了 Socket 连接时长方面的控制。于是我查看了我本地的 Shadowsocks 使用的 Privoxy 的配置文件，这个文件在 MacOS 中位于 /Users/lena/Library/Application Support/ShadowsocksX-NG/privoxy.config 文件。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

toggle  1
enable-remote-toggle 1
enable-remote-http-toggle 1
enable-edit-actions 0
enforce-blocks 0
buffer-limit 4096
forwarded-connect-retries  0
accept-intercepted-requests 0
allow-cgi-request-crunching 0
split-large-forms 0
keep-alive-timeout 5
socket-timeout 60

forward         192.168.*.*/     .
forward         10.*.*.*/        .
forward         127.*.*.*/       .
forward         [FE80::/64]      .
forward         [::1]            .
forward         [FD00::/8]       .
forward-socks5 / 127.0.0.1:1086 .

# Put user privoxy config line in this file.
# Ref: https://www.privoxy.org/user-manual/index.html

可以看到 keep-alive-timeout 和 socket-timeout 这两个选项设定的超时时间都比较低。我做了下面两个尝试：

1. 将这两个设置调高，并重启 Shadowsocks，但随后发现 Privoxy 重置了设置文件；
2. 我手动 kill 掉正在运行的 Privoxy 并且手动使用更新后的 config 文件调起一个新的进程，但是仍然没有解决 Something went wrong 的问题；

至此，我也不想和 Privoxy 纠缠下去，既然问题出在 Socks5 代理转 Http 代理的环节，我们可以使用 Proxifier 这个软件直接使用 Shadowsocks 提供的 Socks5 代理，就可以很好地解决这个问题。

Proxifier 的教程网上非常多，我就不在这篇文章里赘述了。

Proxifier 的使用参加我的文章：如何使用 Proxifier 来进行流量代理控制