最近开发 C++ 的程序在链接阶段发生了一个 LTO 相关的错误。链接时优化（Link Time Optimization, LTO） 是一种编译优化技术，旨在通过在链接阶段执行全程序优化来提升代码性能和减少二进制文件大小。其主要原理是在链接阶段而不是在编译阶段进行更高级的优化，允许跨文件的全局优化。LTO 的基本原理和过程是：

• 中间表示：在编译阶段，编译器将每个源文件编译为一种中间表示（如 LLVM bitcode），而不是直接生成目标代码。
• 全局优化：在链接阶段，链接器将所有中间表示文件合并，生成一个完整的程序表示。此时，优化器可以进行跨文件的全局优化，如函数内联、去除冗余代码和跨模块优化。
• 生成目标文件：优化完成后，链接器生成最终的可执行文件或库。

我遇到的错误信息中的管件一句是:

1

attempt to add bitcode file after LTO (htons)

可以看到错误信息提示我们链接系统试图在 LTO 优化之后添加 bitcode。并且在后面的括号中链接器提到了一个符号 htons，这是来自 libc 库的一个符号。基于的 https://github.com/emscripten-core/emscripten/issues/16836 这个链接中的启发，我发现了一个 LTO 优化可能面临的普遍性问题。这个问题是 LTO 会尝试移除一些它认为不需要的符号从而减少编译出来的程序的体积，但是这个判断可能会不准确。它可能将一些实际会被使用的符号删除。为了解决这个问题，我们可以为链接器指定链接输入，强制保留指定的符号以避免错误的移除。针对我遇到的情况，为链接器加上 -Wl,-u,htons 的配置即可解决问题。

最近在 Unraid 升级 6.12.x 版本以后会偶发性的产生一个 Bug，其表现为 Unraid 网页无法打开（这里是指访问 Unraid IP 地址无法访问 Web 管理界面）。这个问题实际上是由于 Unraid 上的 Nginx 服务失去响应导致的。这种情况下我们只需要干掉 Nginx 进程并重启就可以了。

首先通过 ps -aux | grep nginx 找到 Nginx 主进程的 PID，然后通过 kill -9 <PID> 干掉进程。要再次启动 Nginx，可以运行

1
2

cd /etc/rc.d/
./rc.nginx start

注意通过 ./rc.nginx restart 在正常情况下可以重启 Nginx 服务，但是在 Nginx 处于无法响应的状态时，这个脚本无法杀死 Nginx 进程，必须要手动终止。

在 Ubuntu 中彻底删除一个用户涉及到几个步骤，不仅仅是删除用户，还可能包括删除与用户相关的数据。以下是步骤指南：

1. 确保用户未登录: 在删除用户之前，最好确保该用户未登录。你可以使用 who 命令来检查哪些用户当前已登录。

   1

   who

2. 删除用户: 使用 userdel 命令删除用户。如果你还希望删除用户的主目录和邮件池，可以使用 -r 选项。

   1	sudo userdel -r username

   其中，username 是你想删除的用户的用户名。

   注意：-r 选项会删除用户的主目录（通常是 /home/username）。确保你已经备份了所有重要的数据！

3. 检查文件系统: 即使删除了用户和其主目录，可能仍然在文件系统上遗留一些属于该用户的文件。你可以使用 find 命令来搜索这些文件：

   1	sudo find / -user username

   这将列出所有属于 username 的文件。根据你的需要，你可以手动删除这些文件或更改它们的所有权。

4. 删除用户的 cron 作业: 如果用户配置了任何 cron 作业，你还需要手动删除它们。检查 /var/spool/cron/crontabs/username 是否存在，如果存在，删除它。

   1	sudo rm /var/spool/cron/crontabs/username

5. 其他服务或配置: 如果该用户有其他特定的配置，例如在 /etc/sudoers 中的条目或在其他服务中的特殊访问权限，你需要手动检查并删除它们。

请在进行任何删除操作之前确保备份所有重要数据。确保你明确知道正在执行的操作，避免意外删除重要文件或配置。

遇到这样一个蛋疼的问题，我有一台服务器，上面部署了一个 web 服务，同时我也想把这个服务器作为客户端连入一个 OpenVPN 虚拟网络，并且我希望服务器上的程序能够通过 OpenVPN 的网关来访问外部网络，这主要是为了隐藏服务器的身份。但是在 OpenVPN 连接之后，原有的 Web 服务将无法访问。通过调试分析可以法线，造成这一现象的原因是 Web 服务的响应包也被路由配置路由到 OpenVPN 的 tun0 接口中。这导致响应无法返回给原来的请求服务器。如何解决这个问题呢？

如果你在网络上搜索这类问题你会发现各种文章给出的方案一般都是为 OpenVPN 的配置文件添加 route-nopull 选项来阻止 OpenVPN 设置客户端路由，但是这会导致客户端的对外访问无法通过 VPN 进行。事实上，从 IP 路由的角度来看，如果我的服务器是 A，而某个访问 Web 服务的 IP 是 B，同时 B 也可能是 A 试图访问的外部的目标服务提供者。对传输层路由而言，A 给 B 的 Web 服务响应和 A 主动发往 B 的请求是无法区分的。从这个角度来看，要达成 inbound 和 outbound 流量分别路由似乎是不可能的。

但是其实我们有一个突破点：那就是 Web 服务总是在本机使用固定的端口和请求者通信，我们可以通过端口来区分 inbound 和 outbound 流量。首先我们输入下面的命令：

1

iptables -t mangle -A OUTPUT -p tcp -m multiport --sports 80,443 -j MARK --set-mark 1

在这个命令中，我们会让路由表观察从本地的 80 和 443 端口发出的包，并给这些包打上一个特定的标签（--set-mark 1 的作用）。然后输入下面的命令：

1

ip route add default via [gateway addr of eth0] dev eth0 table 100

这个命令会创建一个新的路由表 table 100，然后在这个表中加入一个默认路由，将流量送往原有的网关。然后再运行下面的命令：

1

ip rule add fwmark 1 table 100

这个命令会让带有标记 1 的包使用 table 100 路由表进行路由。运行完上面的配置后，web 服务就可以正常访问呢了。

以上方法是在 ChatGPT 的协助下摸索出来的，我的提问是：

如何通过 iptables 或者 route 命令，让访问 80 与 443 端口的包使用 tun0 接口，而访问其他端口的包使用 eth0 接口？

GPT 的回答是

1

iptables -t mangle -A OUTPUT -p tcp -m multiport --dports 80,443 -j MARK --set-mark 1

1
2

ip route add default dev tun0 table 100
ip rule add fwmark 1 table 100

1

ip route add default dev eth0

在之前的文章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 来进行流量代理控制