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）交握的特徵辨識 Tor 連線。即使沒有清單，審查者仍可看出「這看起來像 Tor」，然後丟棄連線。Pluggable transport 會移除這項特徵。它會在用戶端將 Tor stream 包裝成其他形式，再由你的 bridge 解開包裝。

obfs4 是大多數 bridge 使用的 transport。它會將 stream 轉換成沒有標頭且沒有固定交握模式的位元組，因此 DPI 沒有可比對的模式。它也會驗證用戶端身分。Bridge line 中的 cert= 值是用戶端必須證明持有的 key，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 開始。之後可以在第 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
  }
]

截至 2026 年 8 月，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 業者處理的申訴郵件也不會送到您這裡。不過，仍請確認供應商的可接受使用政策，因為部分主機商會將任何 Tor 服務視為特殊情況。bridge 與 onion service 在這方面正好相反：bridge 只有在其位址可連線並最終被分發出去時才有用，而同類型 VPS 上的 v3 onion service只有在您的公開 IP 維持隱藏時才有用。

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

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

從 Tor Project 儲存庫安裝 Tor

發行版套件通常較為落後，而 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，並安裝發行版提供的 tor 套件。以下步驟完全相同。

obfs4proxy 套件由 Debian 和 Ubuntu 本身提供（截至 August 2026，Debian 13 的版本為 0.0.14）。請確認二進位檔的安裝位置，因為其路徑必須填入設定檔：

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 會使用這個 loopback 通道，將已建立的連線連同用戶端位址交回 tor。Tor Project 的設定指南會在每個 bridge 中加入這一行，因為沒有它，transport 無法將該位址回報給 tor。

ContactInfo 與 Nickname 都是公開資訊。請使用你會查看的位址，因為 Tor Project 會透過它聯絡你，通知你 bridge 發生問題。如果你希望保持低調，請選擇不會識別你身分的 nickname。

BridgeDistribution 決定由哪個 distributor 將你的位址提供給用戶。可接受的值包括 https、email、telegram、settings、none 和 any。初次設定 bridge 時使用 any，讓系統自行決定。若是自行提供給他人的 private bridge，請使用 none；這會讓該位址完全不列入公開分發。

連接埠選擇的重要性

請勿將 9001 用於這兩個連接埠。Tor Project 已明確如此說明，因為 9001 是傳統的 ORPort，審查者會在網際網路上掃描此連接埠。兩個連接埠也必須彼此不同，因為 tor 和 obfs4proxy 各自會綁定自己的監聽器。

最適合 obfs4 的連接埠是 443。幾乎所有受限制的網路都允許對外連線至 443，而持續較久的連線看起來就像一般的網頁工作階段。綁定 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 會禁止程序取得其父程序原本沒有的任何權限，而 file 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 的實際意義。既然要處理這些設定，也請參閱 使用金鑰與強化的 sshd 設定來鎖定 SSH。主機上的 bridge 即使未列出，只要仍使用密碼 SSH，就仍是一台使用密碼 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'

第一行表示可達性測試通過，descriptor 已傳送至 bridge authority。如果這行始終未出現，表示網際網路與您的伺服器之間的某個環節正在丟棄傳往 ORPort 的網路流量。第二行必須顯示您設定的連接埠。若該行顯示不同的連接埠，表示 tor 從未套用 ServerTransportListenAddr。最常見的原因是 transport 名稱不一致：兩個 directive 都必須寫成 obfs4。

確認兩個 listener 都存在：

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 的暱稱與身分指紋。第二個檔案包含雜湊後的指紋。將此指紋貼到 Relay Search，即可確認 bridge 是否正在執行，以及大約有多少用戶端連線到它。兩者不能互換。bridge line 若包含雜湊值，便無法與 bridge 提供的身分金鑰相符，因此用戶端會拒絕剛建立的連線。

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

你不應將橋接器資訊直接交給任何人。描述資訊送達橋接器權威後，發佈系統 rdsys（BridgeDB 的後繼者）會將你的橋接器指派給一個發佈者，使用者則向該發佈者索取橋接器。截至 August 2026，管道如下：

• 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 的原文表示，"It can take several days or weeks until you see a consistent set of users." 初次的 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。

/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 位址不會以請求來源的身分出現在任何網站日誌中，而這正是 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 的用戶端會連線至沒有服務監聽的連接埠，然後放棄連線。伺服器的公開 IP 變更時也會發生相同情況。請在設定期間選定連接埠，之後不要變更。