运维 | 当 RSS 阅读器遇上 WARP：给 TTRSS 装一个 Cloudflare 加速器

Tiny Tiny RSS 一直在 Oracle Cloud 的 VPS 上平稳运行着。但有一个老问题始终没解决：总有那么些 RSS 源，要么超时，要么连不上。

有些是被墙了，有些是源站对机房 IP 做了限流，有些纯粹是路由绕路导致延迟太高。之前试过换 DNS、调间隔、改 User-Agent，效果都不理想。

后来看到 Cloudflare WARP——一个免费的 WireGuard VPN 服务。如果把 RSS 抓取的出站流量从 WARP 走，等于换了出口 IP，而且走的是 Cloudflare 的网络，路由自然会好很多。

但问题来了：我不想让整台 VPS 的流量都走 WARP。

这台机器上还跑着博客、反向代理、管理面板——这些服务需要从原 IP 出站。WARP 官方的客户端装上就是全局模式，没有按进程分流的能力。

解法：wireproxy

wireproxy 是一个轻量级工具，它能把 WireGuard 隧道包装成一个 SOCKS5 代理。这样只有主动连接这个代理的流量才走 WARP，其他所有流量保持原样。

架构是这样：

TTRSS 容器 ──SOCKS5:40000──→ wireproxy ──WireGuard──→ Cloudflare WARP 边缘节点 ──→ 目标网站

注册 WARP

首先需要拿到 WARP 的 WireGuard 配置。用的是 wgcf 这个第三方工具：

# 注册 WARP 账户
wgcf register --accept-tos

# 生成 WireGuard 配置文件
wgcf generate

# 得到 wgcf-profile.conf

Cloudflare WARP 的 WireGuard 配置内容大致是：

[Interface]
PrivateKey = xxxx
Address = 172.16.0.2/32
DNS = 1.1.1.1

[Peer]
PublicKey = xxxx
AllowedIPs = 0.0.0.0/0
Endpoint = engage.cloudflareclient.com:2408

注意 AllowedIPs = 0.0.0.0/0——如果直接用这个配置文件启动 WireGuard，所有流量都会走 WARP。wireproxy 正是为了解决这个问题而生。

配置 wireproxy

wireproxy 的配置文件很简洁：

[Socks5]
BindAddress = 0.0.0.0:40000

[Peer]
PublicKey = xxxx
Endpoint = engage.cloudflareclient.com:2408
AllowedIPs = 0.0.0.0/0

[Interface]
PrivateKey = xxxx
Address = 172.16.0.2/32
DNS = 1.1.1.1

SOCKS5 代理监听在 0.0.0.0:40000，WireGuard 连接 Cloudflare 的边缘节点。注意这里仍然有 AllowedIPs = 0.0.0.0/0——但它只影响从 WARP 隧道出去的数据包，不影响宿主机上其他不走 SOCKS5 的流量。

TTRSS 容器配置

TTRSS 容器需要设置 HTTP_PROXY/HTTPS_PROXY 环境变量，让 curl 和 PHP 的 HTTP 请求走 SOCKS5 代理：

services:
  ttrss:
    image: lscr.io/linuxserver/ttrss:latest
    environment:
      - HTTP_PROXY=socks5://172.26.0.1:40000
      - HTTPS_PROXY=socks5://172.26.0.1:40000
      - NO_PROXY=localhost,127.0.0.1,::1,192.168.0.0/16,10.0.0.0/8

其中 172.26.0.1 是 Docker 默认 bridge 网络的宿主机地址。TTRSS 容器通过这个地址连接 wireproxy，走 WARP 出站。而访问数据库、内部 API 等不走代理的流量，通过 NO_PROXY 排除。

systemd 守护

为了让 wireproxy 开机自启和意外退出后自动恢复，配置了一个 systemd 服务：

[Unit]
Description=WireProxy WARP SOCKS5
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/wireproxy -c /root/warp-proxy/wireproxy.conf
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

验证

curl -s --proxy socks5://localhost:40000 https://www.cloudflare.com/cdn-cgi/trace

返回结果：

fl=22f409
ip=104.28.206.182
colo=NRT
loc=JP
warp=on

warp=on → 确认流量走了 WARP
ip=104.28.206.182 → 出口 IP 是 Cloudflare 分配的地址
colo=NRT / loc=JP → 从 Cloudflare 日本东京节点出站

对比一下没有代理时的出口：

curl -s https://www.cloudflare.com/cdn-cgi/trace | grep ip
# ip=xxx.xxx.xxx.xxx  ← Oracle Cloud 原始 IP

两次请求在同一台机器上运行，出口 IP 完全不同。

几个值得注意的细节

1. 出口 IP 不是固定的

WARP 分配的 IP 来自 Cloudflare 的共享 IP 池，重启 wireproxy 或重连后 IP 可能变化。但对于 RSS 阅读器来说这不是问题——RSS 源站不会做 IP 白名单检查，关键是从 Cloudflare 网络出去，路由好、不被墙。

2. 为什么不用 WARP 官方客户端

WARP 官方客户端（cloudflare-warp）是全局 VPN 模式，装上之后整台机器的流量都从 WARP 走。对于单用途的机器可能可以接受，但对于同时跑博客、反向代理的服务器，会带来两个问题：

博客的真实访客 IP 会被 WARP 覆盖，日志里全是 Cloudflare 的 IP
如果 WARP 断连，所有服务都断网

wireproxy 的方案把选择权交给应用层——只有设置了代理的进程走 WARP，其他一切照旧。

3. SOCKS5 的性能开销

WireGuard 本身非常轻量（内核级实现），SOCKS5 协议的开销也很小。实测抓取 RSS 源的时间没有明显增加，大多数情况下反而因为路由优化而更快了。

适用场景

这个方案的核心思路是：给特定的出站流量换一个网络出口。

RSS 阅读器抓取被墙/限流的源 ✓
爬虫、API 调用需要更换出口 IP ✓
某个容器需要独立代理通道 ✓
全服务器 VPN ✗（这种场景用 WARP 官方客户端或其他 WireGuard 方案更合适）

最终效果很简单：那些之前超时或失败的 RSS 源，现在能正常抓取了。而博客、面板、反向代理完全不受影响，甚至不知道有 WARP 的存在。

2026 年 7 月，于 VPS1。

配置由 Hermes Agent 辅助完成。

文章目录