如何在 VPS 上架設 obfs4 Tor bridge？

Tor bridge 是什麼，以及它存在的原因

Tor bridge 是通往 Tor network 的入口，其位址不會發布在公開的 relay 清單中。這份清單稱為 consensus，是任何人都能下載的簽署文件，審查者也會下載。封鎖其中列出的 Tor relay 只需一個下午：先取得 consensus，再在邊界封鎖其中的每個位址。Bridge 的存在是因為公開清單是弱點。Bridge 位址會分批少量提供，因此單次請求不會交出完整集合。

未列出的位址只解決了一半問題。Deep packet inspection (DPI) 會依內容而非位址分類流量，並可根據 TLS (transport layer security) handshake 的特徵辨識 Tor connection。即使沒有清單，審查者仍能看出「這看起來像 Tor」並丟棄 connection。Pluggable transport 能移除這個訊號。它會在 client 端將 Tor stream 包裝成其他形式，再由你的 bridge 解開包裝。

obfs4 是大多數 bridge 使用的 transport。它會將 stream 轉換成沒有 header、也沒有固定 handshake 的 bytes，因此 DPI 沒有可比對的模式。它也會驗證 client 身分。bridge line 中的 cert= 值是一把 key，client 必須先證明自己持有這把 key，bridge 才會回應。這能阻擋 active probing：審查者若連線到你的位址，測試該位址是否提供 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 開始。之後可以在第 2 個位址上新增 WebTunnel bridge：如果兩者使用同一個 IP，單一位址遭封鎖就會同時使兩者失效。

執行 bridge 需要付出什麼代價？

[
  {
    "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 是第 一 個 hop。流量離開你的伺服器後，會前往另一個 Tor relay，不會直接前往使用者選定的網站。你的 IP 位址不會以請求來源的身分出現在陌生人的網站日誌中，因此 exit relay operator 處理的申訴信不會寄到這裡。不過仍應確認供應商的 acceptable use policy，因為部分主機商會將任何 Tor 服務視為特殊情況。

有一件事不要做：在相同位址上，將現有的公開 relay 轉換成 bridge。Tor Project 對這種情況的建議是變更「IP address、name 與 fingerprint」，因為審查者下載的 consensus 已經包含舊位址。上週還是公開 relay 的 bridge，現在已經是出現在封鎖清單上的 bridge。

正常運作時間比速度更重要。relay 要求指出：「如果你的 relay 每天停止執行超過 2 小時，其效用就會受到限制」。在這方面，bridge 的情況比 relay 更差，因為每個用戶端只有一個位址，沒有備援位址。重新啟動會讓其上的所有使用者中斷。請針對 obfs4 埠在 Uptime Kuma 中設定 TCP 埠檢查，這樣服務停止回應的當天就能得知。

從 Tor Project 儲存庫安裝 Tor

Distribution 套件通常較舊，而 bridge 屬於應保持在最新狀態的安全性軟體。先加入專案自有的儲存庫。

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，然後安裝您所用 distribution 提供的 tor 套件。以下步驟完全相同。

obfs4proxy 套件由 Debian 和 Ubuntu 官方提供（截至 August 2026，Debian 13 的版本為 0.0.14）。請確認 binary 的安裝位置，因為其路徑會寫入設定檔：

command -v obfs4proxy || command -v lyrebird

上游已將專案重新命名為 lyrebird，因此較新的套件可能會安裝 /usr/bin/lyrebird。請使用該命令輸出的路徑。

在 /etc/tor/torrc 中設定 bridge

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 將自己的 descriptor 傳送給 bridge authority，而不是傳送到公開的 consensus。正是這一行讓 relay 不會列入公開清單。

ORPort 是實際的 Tor 埠。它必須能從網際網路連入，因為 tor 會測試這個埠；測試通過前，tor 不會發布 descriptor。

ServerTransportPlugin 會指定要執行的命令。tor 會將 obfs4proxy 啟動為子程序，並透過 pipe 與它通訊。因此，obfs4proxy 不需要自己的 service unit，也不會出現在 systemctl status 中。

ServerTransportListenAddr 會固定 obfs4proxy 監聽的埠。省略這一行時，obfs4proxy 會在啟動時選擇可用埠。大多數重新啟動後，選到的埠都會不同，因此你先前提供的每一行 bridge 資訊都會指向沒有服務監聽的埠。這些用戶端會收到連線遭拒，之後便停止嘗試連線。

ExtORPort auto 會開啟 extended ORPort。這是 obfs4proxy 用來將已建立的連線連同用戶端位址交回 tor 的 loopback channel。Tor Project 的設定指南會在每個 bridge 中加入這一行，因為沒有它，transport 就無法將該位址回報給 tor。

ContactInfo 與 Nickname 都是公開資訊。請使用你會定期查看的位址，因為 Tor Project 會透過它通知你 bridge 發生故障的情況。如果你希望保持低調，請選擇不會識別你身分的暱稱。

BridgeDistribution 會選擇將你的位址提供給用戶的 distributor。可接受的值包括 https、email、telegram、settings、none 和 any。首次建立 bridge 時請使用 any，讓系統自行決定。若是由你自行提供給他人的 private bridge，請使用 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 無法得知這層設定。若伺服器本身有規則，但控制面板中沒有對應規則，bridge 便無法連線，也不會發布 descriptor。若其中任何一部分對你而言是新的，請參閱全新 VPS 所需的 ufw 規則與Linux 中 listening port 的實際意義。設定防火牆時，也請使用 keys 與強化的 sshd 設定鎖定 SSH。在仍使用密碼 SSH 的伺服器上，即使 bridge 未列出，伺服器仍然是使用密碼 SSH 的伺服器。

啟動服務，然後讀取日誌

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

Debian 和 Ubuntu 會提供兩個 unit。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'

第一行表示可連線性測試已通過，且描述元已傳送至 bridge authority。如果這行從未出現，表示網際網路與伺服器之間的某個環節正在丟棄傳往 ORPort 的網路流量。第二行必須顯示你設定的埠號。如果顯示其他埠號，表示 tor 從未套用 ServerTransportListenAddr。最常見的原因是 transport 名稱不一致：兩個指令都必須寫成 obfs4。

確認兩個監聽程序都存在：

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

我的 bridge line 在哪裡？

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

第一個檔案包含 bridge line 所需的 nickname 與身分指紋。第二個檔案包含雜湊後的指紋；將此值貼到 Relay Search，即可確認 bridge 是否正在運作，以及大約有多少用戶端連線至該 bridge。兩者不可互換。若 bridge line 使用雜湊值，便無法與 bridge 提供的身分金鑰相符，因此用戶端會拒絕剛建立的連線。

橋接器實際上如何接觸到使用者？

您不需要把橋接器連線資訊交給任何人。描述檔抵達橋接器權威伺服器後，分發系統（rdsys，BridgeDB 的後繼者）會將您的橋接器指派給一個分發器，使用者再向該分發器索取橋接器。截至 2026 年 8 月，取得管道如下：

• bridges.torproject.org/options 的網頁表單，通過 captcha 後會提供橋接器連線資訊。
• 從 Gmail 或 Riseup 地址寄信至 bridges@torproject.org，系統會回覆橋接器連線資訊。限制寄件服務商是因為，若允許無限量的免費帳號，單一審查者就能列舉出所有橋接器。
• Telegram bot @GetBridgesBot。傳送 /start，接著傳送 /obfs4 或 /webtunnel。
• Tor Browser 本身的 Settings，再進入 Connection；其中的「Request bridges」會透過 moat channel 取得橋接器。

新橋接器完成設定後，大約 3 小時會出現在 Relay Search。使用者需要更久才會出現：Tor Project 的原文是：「可能需要數天或數週，才能看到一組穩定的使用者。」開始的 2 週沒有明顯流量很正常，不代表設定有問題。

設定 BridgeDistribution none 會退出所有這些分發管道。之後，您可以透過審查者無法讀取的管道，將橋接器連線資訊傳給需要的人。

發生問題時

日誌中沒有自我測試訊息。 ORPort 無法連線。請從另一台機器使用 nc -vz your.ip 8443 進行測試。連線持續等待表示封包遭到丟棄，因此請檢查 ufw 與供應商的控制面板。連線遭拒表示 tor 未監聽該埠，因此請檢查 ss -lntp，並查看日誌中的設定錯誤。

已註冊的 transport 顯示了您未選擇的埠。 tor 忽略了 ServerTransportListenAddr。transport 名稱必須與 ServerTransportPlugin 中的名稱完全一致，而且兩者都必須是 obfs4。

obfs4proxy 無法繫結 443 埠。 使用 getcap /usr/bin/obfs4proxy 確認 capability，再使用 systemctl show tor@default -p NoNewPrivileges 確認覆寫設定已套用至 unit。若輸出 NoNewPrivileges=yes，表示您的 drop-in 套用了錯誤的 unit，而該 unit 並未執行。

/var/lib/tor/pt_state/ 中沒有任何內容。 tor 從未啟動 transport，表示 ServerTransportPlugin 中的路徑錯誤。請與 command -v obfs4proxy 的輸出比對。

變更後用戶端停止連線。 變更位址或 obfs4 埠後，先前已散發的所有 bridge line 都會失效。也請確認伺服器的公開 IP 是否變更；部分供應商在重建伺服器時會發生這種情況。

tor 完全無法啟動。 執行 sudo -u debian-tor tor --verify-config -f /etc/tor/torrc。此指令會剖析檔案、輸出發現問題的行，且不會影響目前執行中的服務。

FAQ

VPS 供應商會因為我執行 Tor bridge 而提出申訴嗎？

bridge 是入口點，因此離開伺服器的網路流量會前往其他 Tor relay，不會前往使用者選擇的網站。您的 IP 位址不會以請求來源的身分出現在任何人的 Web log 中；這正是 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 server、有效的 TLS 憑證，以及至少 1 GB RAM。如果同時執行兩者，請使用不同的位址，否則封鎖 1 個 IP 會同時移除 2 個 bridge。

之後變更 obfs4 連接埠會發生什麼事？

所有已分發的 bridge line 都會停止運作。bridge line 會將位址、連接埠、fingerprint 和憑證綁定在一起，因此持有舊 bridge line 的 client 會連線到沒有服務監聽的連接埠，然後放棄。伺服器的公開 IP 變更時也一樣。請在設定期間選定連接埠，之後不要再變更。