SSD Nodes Learn Hosting plans →
指南 Matt Connor作者: Matt Connor · 更新于 2026-08-23

如何在VPS上运行obfs4 Tor Bridge

用一台低价VPS部署obfs4 Tor bridge:配置torrc指令、选择两个TCP端口、设置防火墙,并通过日志确认运行成功,最后获取bridge line供用户连接。

Tor bridge 是什么,以及它为何存在

Tor bridge 是进入 Tor 网络的入口点,但其地址不会发布在公共中继列表中。该列表称为 consensus,是任何人都可以下载的签名文档,审查者也会下载它。通过列表阻断 Tor 只需一个下午:获取 consensus,然后在边界处丢弃其中的每个地址。Bridge 存在的原因是,公开列表是薄弱点。Bridge 地址会分批少量提供,因此单个请求不会交出完整地址集。

地址未列入列表只是解决了一半问题。深度数据包检测(DPI)不根据地址,而是根据内容对流量分类;它可以从 TLS(传输层安全)握手的特征识别 Tor 连接。即使没有地址列表,审查者仍可判断“这看起来像 Tor”,然后丢弃连接。可插拔传输会移除这一信号。它在客户端将 Tor 流封装成其他形式,然后由您的 bridge 解封装。

obfs4 是大多数 bridge 使用的传输方式。它将流转换为没有标头、没有固定握手的数据,因此 DPI 没有可匹配的模式。它还会对客户端进行身份验证。bridge line 中的 cert= 值是一个密钥,客户端必须证明自己持有该密钥,bridge 才会响应。这样可以抵御主动探测:审查者连接到您的地址,测试该地址是否提供 Tor 服务时,不会收到任何回复,也无法获知任何信息。

应运行哪种可插拔传输?

  • obfs4 需要1台 VPS、2个 TCP 端口,且不需要域名。这是最容易部署且实用的方案,也是本指南的主题。
  • WebTunnel 将连接隐藏在发往真实网站的普通 HTTPS 流量中。Tor Project 列出的要求包括:静态 IPv4 地址、由您控制的域名、可正常工作的 Web 服务器(例如 NGINX 或 Apache)、有效的 TLS 证书,以及至少1 GB RAM,建议使用4 GB。它适用于随机特征流量本身就容易引起怀疑的网络,因为即使某个国家几乎只允许网页浏览,通常仍会允许 HTTPS。
  • Snowflake 是另一种参与方式。志愿者运行短期 WebRTC 代理,因此入口点会不断变化,审查者没有稳定地址可供封锁。您不需要为它运行 bridge,而是运行 proxy,且不需要固定地址。

请从 obfs4 开始。之后可以在第二个地址上添加 WebTunnel bridge:如果两者使用同一个 IP,单个被封锁的地址就会同时导致两者不可用。

运行 bridge 需要承担哪些成本?

ChartTor Project published minimum bandwidth, August 2026
The data behind this chart
[
  {
    "label": "Bridge, minimum",
    "min_upstream_mbit": 1
  },
  {
    "label": "Guard or middle relay, minimum",
    "min_upstream_mbit": 10
  },
  {
    "label": "Guard or middle relay, recommended",
    "min_upstream_mbit": 16
  }
]

截至 August 2026,Tor Project 要求 bridge 至少提供 1 Mbit/s 的上行和下行带宽。对于 guard 或 middle relay,要求为 10 Mbit/s,并建议达到 16 Mbit/s。这些是公开发布的要求,不是实际测量值。新 bridge 通常会在数周内远低于自身的最低要求。同一要求页面还要求 relay 每月至少产生 100 GByte 的出站流量,而最小规格的套餐已经可以满足这一要求。因此,在选择更大规格前,请先阅读 小型 VPS 每月的实际费用。

滥用风险面较小,这是最容易被误解的地方。bridge 是第一个跳点。离开您服务器的流量会发送到另一个 Tor relay,而不会直接发送到用户选择的网站。您的 IP 地址不会作为请求来源出现在陌生网站的 Web 日志中,因此不会收到 exit relay 运营者经常处理的投诉邮件。不过,仍应检查提供商的可接受使用政策,因为某些主机会将任何 Tor 服务视为特殊情况。在这一点上,bridge 和 onion service 正好相反:bridge 只有在其地址可访问并最终被分发出去时才有用,而同类 VPS 上的 v3 onion service只有在您的公网 IP 不被暴露时才有用。

不要进行以下操作:将现有的公网 relay 在同一地址上转换为 bridge。Tor Project 对这种情况的建议是更改“IP address、name and fingerprint”,因为旧地址已经存在于审查方下载的 consensus 中。上周还是公网 relay 的 bridge,很可能已经位于封锁列表中。

运行时间比速度更重要。relay 要求指出:“如果您的 relay 每天运行时间不足 2 小时,其作用会受到限制”。在这一点上,bridge 的情况比 relay 更差,因为每个客户端只有一个地址,没有备用地址。服务每重启一次,所有连接到它的用户都会断开。请设置 在 Uptime Kuma 中检查 TCP 端口,监控 obfs4 端口,以便在它停止响应当天发现问题。

从 Tor Project 软件源安装 Tor

发行版软件包通常滞后,而网桥属于安全软件,应保持最新。请先添加项目自己的软件源。

sudo apt update
sudo apt install -y apt-transport-https gnupg wget lsb-release
wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

现在创建源文件。Suites: 行必须包含您的发行版代号,因此请从系统读取该值,不要凭记忆手动输入。

sudo tee /etc/apt/sources.list.d/tor.sources >/dev/null <<EOF
Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: $(lsb_release -cs)
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg
EOF
sudo apt update
sudo apt install -y tor deb.torproject.org-keyring obfs4proxy

如果 apt update 报告该软件源没有适用于您代号的 Release 文件,说明 Tor Project 不提供该发行版。删除 /etc/apt/sources.list.d/tor.sources,再次运行 sudo apt update,然后安装发行版提供的 tor 软件包。下面的步骤完全相同。

obfs4proxy 软件包由 Debian 和 Ubuntu 自己提供(截至 August 2026,Debian 13 中的版本为 0.0.14)。请确认二进制文件的安装位置,因为该路径需要写入配置:

command -v obfs4proxy || command -v lyrebird

上游项目已更名为 lyrebird,因此较新的软件包可能会改为安装 /usr/bin/lyrebird。使用该命令输出的路径。

在 /etc/tor/torrc 中配置桥接

BridgeRelay 1
ORPort 8443
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ServerTransportListenAddr obfs4 0.0.0.0:9443
ExtORPort auto
ContactInfo you@example.com
Nickname PickANickname
BridgeDistribution any

这些配置行中的每一行都可能导致故障,因此请逐行处理。

BridgeRelay 1 告诉 tor 将自身描述符发送给桥接权威,而不是发送到公共共识。正是这一行使中继不出现在公开列表中。

ORPort 是实际的 Tor 端口。它必须可以从互联网访问,因为 tor 会测试该端口。测试通过后,tor 才会发布描述符。

ServerTransportPlugin 指定 tor 要运行的命令。tor 将 obfs4proxy 作为子进程启动,并通过管道与其通信。因此,obfs4proxy 不需要单独的服务单元,也不会显示在 systemctl status 中。

ServerTransportListenAddr 固定 obfs4proxy 监听的端口。如果省略这一行,obfs4proxy 会在启动时选择一个空闲端口。大多数重启后,它会选择不同的端口。这样,已经分发出去的每条桥接配置都会指向一个没有进程监听的端口。客户端会收到连接被拒绝的错误,随后停止重试。

ExtORPort auto 打开扩展 ORPort。这是 obfs4proxy 用于将已建立的连接及客户端地址交回 tor 的回环通道。Tor Project 的配置指南会在每个桥接配置中加入这一项,因为没有它,传输层无法将客户端地址报告给 tor。

ContactInfo 和 Nickname 都会公开。请使用你会查看的地址,因为 Tor Project 会通过它联系你,通知你桥接出现故障。如果希望保持低调,请选择不会暴露身份的昵称。

BridgeDistribution 选择将你的地址分发给用户的分发器。可接受的值包括 https、email、telegram、settings、none 和 any。首次配置桥接时使用 any,让系统自动决定。对于自行分发的私有桥接,使用 none,这样该地址完全不会进入公开分发流程。

为什么端口选择很重要

不要将两个端口都设置为 9001。Tor Project 已明确说明原因:9001 是传统的 ORPort,审查者会扫描互联网中的该端口。两个端口也必须彼此不同,因为 tor 和 obfs4proxy 会分别绑定各自的监听端口。

obfs4 最适合使用的端口是 443。几乎所有受限网络都允许出站 443 流量,连接长时间保持时,看起来也像普通的 Web 会话。绑定 1024 以下的端口需要额外执行一个步骤,因为 obfs4proxy 不以 root 身份运行:

sudo setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy
sudo systemctl edit tor@.service tor@default.service

在每个打开的编辑器中添加以下两行:

[Service]
NoNewPrivileges=no

仅设置此 capability 还不够。systemd 的 NoNewPrivileges 会阻止进程获得其父进程没有的任何权限,而文件 capability 正属于这类权限。因此,只要该设置保持启用,obfs4proxy 就无法绑定 443。

如果不想执行该步骤,请选择一个不引人注意的高位端口,并记录下来。无论选择哪个端口,之后都不要更改 obfs4 端口。bridge line 会将地址、端口、指纹和证书绑定在一起,因此只要端口发生变化,用户浏览器中已经保存的每一份配置都会立即失效。

在两道防火墙上开放端口

sudo ufw allow 8443/tcp
sudo ufw allow 9443/tcp
sudo ufw status

两个端口都必须开放。大多数服务商还会在控制面板中运行第二道防火墙,而 ufw 无法感知该防火墙。如果服务器上的规则已存在,但控制面板中没有对应规则,桥接就无法访问,也不会发布描述符。如果其中任何一部分对您来说是新的,请参阅全新 VPS 所需的 ufw 规则和Linux 中监听端口的实际含义。此外,请参阅使用密钥并加固 sshd 配置来锁定 SSH。在启用密码 SSH 的服务器上,即使桥接未列出,该服务器仍然启用了密码 SSH。

启动服务,然后查看日志

sudo systemctl enable --now tor.service
sudo systemctl restart tor.service
sudo journalctl -e -u tor@default

Debian 和 Ubuntu 提供两个单元。tor.service 是一个小型包装单元,tor@default.service 才是执行实际工作的进程。因此,journalctl -u tor 看起来几乎为空,而所需日志位于 tor@default 下。

以下两行表示运行正常:

Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Registered server transport 'obfs4' at '0.0.0.0:9443'

第一行表示可达性测试通过,并且描述符已发送到桥接 authority。如果这行始终不出现,说明互联网与您的服务器之间的某个环节丢弃了发往 ORPort 的流量。第二行必须显示您配置的端口。如果这里显示的是其他端口,说明 tor 从未应用 ServerTransportListenAddr。通常原因是传输名称不匹配:两个指令中都必须写成 obfs4。

确认两个监听器都已存在:

sudo ss -lntp | grep -E 'tor|obfs4|lyrebird'

我的桥接线路在哪里?

obfs4proxy 会在 tor 的数据目录中写入一个模板:

sudo cat /var/lib/tor/pt_state/obfs4_bridgeline.txt

该目录归 tor 用户所有,权限模式为 700。因此,如果没有 sudo,就会得到 Permission denied。文件中包含如下格式的线路:

Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=<CERTIFICATE> iat-mode=0

将 <IP ADDRESS> 替换为服务器的公网地址,将 <PORT> 替换为 obfs4 端口,而不是 ORPort;将 <FINGERPRINT> 替换为 tor 写入其数据目录的身份指纹:

sudo cat /var/lib/tor/fingerprint
sudo cat /var/lib/tor/hashed-fingerprint

第一个文件包含桥接线路所需的昵称和身份指纹。第二个文件包含经过哈希处理的指纹。将该指纹粘贴到 中继搜索 中,可以查看桥接是否正在运行,以及大致有多少客户端连接到它。这两个值不能互换。桥接线路中如果使用经过哈希处理的值,就无法匹配桥接所提供的身份密钥,因此客户端会拒绝刚刚建立的连接。

桥实际上如何触达用户?

您不能将桥接线路交给任何人。描述符到达桥接权威节点后,分发系统(rdsys,BridgeDB 的后继系统)会将您的桥接分配给一个分发器,用户再向该分发器请求桥接。截至 2026 年 8 月,可用方式如下:

  • 通过 bridges.torproject.org/options 上的 Web 表单提交请求。通过 captcha 后,页面会提供桥接线路。
  • 从 Gmail 或 Riseup 地址向 bridges@torproject.org 发送邮件,系统会回复桥接线路。限制邮箱提供商是因为无限量的免费账户会让审查者枚举出所有桥接。
  • 使用 Telegram 机器人 @GetBridgesBot。发送 /start,然后发送 /obfs4 或 /webtunnel。
  • 在 Tor Browser 中依次打开 Settings 和 Connection,使用“Request bridges”通过 moat 通道获取桥接。

新桥接在完成配置约 3 小时后会显示在 Relay Search 中。用户出现所需的时间要长得多:Tor Project 的原文是:“It can take several days or weeks until you see a consistent set of users.” 开始两周内没有多少用户属于正常情况,不是故障。

设置 BridgeDistribution none 后,桥接不会进入上述任何分发渠道。此时,您可以通过审查者无法读取的渠道,将桥接线路发送给需要它的人。

出现问题时

日志中没有自检行。 ORPort 无法访问。使用另一台机器通过 nc -vz your.ip 8443 进行测试。长时间无响应表示数据包被丢弃,因此请检查 ufw 和服务商控制面板。连接被拒绝表示 tor 未监听该端口,因此请检查 ss -lntp,并查看日志中是否存在配置错误。

已注册的传输显示的端口不是您选择的端口。 tor 忽略了 ServerTransportListenAddr。传输名称必须与 ServerTransportPlugin 中的名称完全匹配,并且两者都必须是 obfs4。

obfs4proxy 无法绑定端口 443。 使用 getcap /usr/bin/obfs4proxy 确认权限,再使用 systemctl show tor@default -p NoNewPrivileges 确认覆盖配置已应用到该单元。如果输出 NoNewPrivileges=yes,说明您的 drop-in 配置写入了一个未运行的单元。

/var/lib/tor/pt_state/ 中没有任何内容。 tor 从未启动该传输,这表示 ServerTransportPlugin 中的路径错误。将其与 command -v obfs4proxy 的输出进行比较。

更改后客户端停止连接。 更改地址或 obfs4 端口后,之前分发的所有 bridge line 都会失效。同时检查服务器的公网 IP 是否发生变化;某些服务商在重建服务器时会分配新的公网 IP。

tor 完全无法启动。 运行 sudo -u debian-tor tor --verify-config -f /etc/tor/torrc。该命令会解析文件,输出出错的行,但不会影响正在运行的服务。

FAQ

我的 VPS 提供商会因 Tor bridge 投诉吗?

bridge 是入口点,因此从您的服务器发出的流量会前往其他 Tor relay,而不会前往用户选择的网站。您的 IP 地址不会作为请求来源出现在任何人的 Web 日志中,而这正是 exit relay 运营者需要处理投诉的原因。各提供商的托管规则仍然不同,有些提供商会将任何 Tor 服务视为特殊情况。因此,请在开始前阅读可接受使用政策,并将您查到的地址填入 ContactInfo。

Tor bridge 会使用多少带宽?

公布的最低带宽为上行和下行各 1 Mbit/s;guard 或 middle relay 则为 10 Mbit/s。实际使用量接近 0,因为您的 bridge 只承载 distributor 分配给它的用户流量。如果您需要设置硬性上限,请在 torrc 中设置 RelayBandwidthRate 和 RelayBandwidthBurst。

为什么没有人连接到我的新 bridge?

bridge 大约需要 3 小时才会出现在 Relay Search 中。Tor Project 的指导意见是,形成一组稳定的用户需要几天或几周。请检查 descriptor 是否已发布;该信息位于 journalctl -u tor@default 中的自检行。然后在 Relay Search 中查找经过哈希处理的 fingerprint,并确认 BridgeDistribution 未设置为 none。

我应该运行 obfs4 还是 WebTunnel?

如果这是您的第一个 bridge,请运行 obfs4:只需要 1 台 VPS 和 2 个端口,不需要域名或证书。如果随机特征的流量本身会被阻断,请运行 WebTunnel,因为它需要您控制的域名、真实的 Web 服务器、有效的 TLS 证书,以及至少 1 GB RAM。如果同时运行两者,请为它们使用不同的地址,否则一个 IP 被阻断就会同时使 2 个 bridge 失效。

如果之后更改 obfs4 端口,会发生什么?

已经分发的每一行 bridge line 都会停止工作。bridge line 会将地址、端口、fingerprint 和证书绑定在一起,因此持有旧 bridge line 的客户端会连接到一个没有进程监听的端口,然后放弃连接。服务器的公网 IP 发生变化时也一样。请在设置时选择端口,并保持不变。