Paano Magpatakbo ng Tor obfs4 Bridge sa VPS

Ano ang Tor bridge at bakit ito umiiral

Ang Tor bridge ay entry point papunta sa Tor network na hindi inilalathala ang address nito sa public relay list. Ang listahang ito, na tinatawag na consensus, ay isang signed document na maaaring i-download ng sinuman, pati ng censor. Madaling i-block ang Tor gamit ito: i-fetch ang consensus, saka i-drop sa border ang bawat address na nakalista rito. Umiiral ang mga bridge dahil ang published list ang mahinang punto. Paisa-isa o kaunti lamang ibinibigay ang mga bridge address, kaya walang isang request ang makakakuha ng buong set.

Kalahati lamang ng solusyon ang address na wala sa listahan. Ang deep packet inspection (DPI), na nagkakategorya ng traffic batay sa content nito sa halip na sa address, ay nakakakilala ng Tor connection mula sa hugis ng TLS (transport layer security) handshake nito. Kahit walang listahan, makikita pa rin ng censor na “mukhang Tor ito” at maaari nitong i-drop ang connection. Tinatanggal ng pluggable transport ang signal na iyon. Binabalot nito ang Tor stream sa ibang anyo sa client side, at inaalis ng iyong bridge ang balot na ito.

Ang obfs4 ang transport na ginagamit ng karamihan sa mga bridge. Ginagawa nitong bytes na walang header at walang fixed handshake ang stream, kaya walang pattern na matutugma ang DPI. Ina-authenticate din nito ang client. Ang cert= value sa loob ng bridge line ay isang key na dapat patunayang hawak ng client bago sumagot ang bridge, kaya napipigilan ang active probing: kapag kumonekta ang censor sa iyong address upang subukan kung Tor ang ginagamit nito, walang reply na matatanggap at wala itong matututunan.

Anong pluggable transport ang dapat mong gamitin?

• obfs4 ay nangangailangan ng isang VPS, dalawang TCP port, at walang domain name. Ito ang pinakamadaling kapaki-pakinabang na setup na maaari mong patakbuhin, at ito ang paksa ng gabay na ito.
• Itinatago ng WebTunnel ang koneksyon sa loob ng karaniwang HTTPS traffic patungo sa isang totoong website. Inililista ng Tor Project ang mga requirement nito bilang static IPv4 address, domain na kontrolado mo, gumaganang web server gaya ng NGINX o Apache, valid na TLS certificate, at hindi bababa sa 1 GB RAM; 4 GB ang inirerekomenda. Angkop ito sa mga network kung saan kahina-hinala na agad ang traffic na mukhang random, dahil kahit ang bansang mahigpit na naglilimita sa ibang uri ng traffic ay karaniwang nagpapahintulot pa rin sa HTTPS.
• Iba ang kontribusyon sa Snowflake. Nagpapatakbo ang mga volunteer ng panandaliang WebRTC proxy, kaya patuloy na nagbabago ang mga entry point at walang stable address na maaaring i-block ng censor. Hindi ka magpapatakbo ng bridge para rito. Proxy ang patatakbuhin mo, at hindi ito nangangailangan ng fixed address.

Magsimula sa obfs4. Maaari kang magdagdag ng WebTunnel bridge sa ibang pagkakataon, sa ikalawang address. Kapag parehong tumatakbo sa iisang IP ang mga ito, sapat na ang pag-block sa isang address upang parehong ma-disable.

Ano ang gastos ng pagpapatakbo ng 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
  }
]

Noong August 2026, hinihingi ng Tor Project sa isang bridge ang hindi bababa sa 1 Mbit/s na upstream at downstream bandwidth. Para sa guard o middle relay, hinihingi ang 10 Mbit/s, at inirerekomenda ang 16 Mbit/s. Mga inilathalang requirement ang mga ito, hindi mga aktuwal na sukat. Karaniwang mas mababa nang malaki ang bagong bridge sa sarili nitong minimum sa loob ng ilang linggo. Sa parehong requirements page, hinihingi sa isang relay ang hindi bababa sa 100 GByte na outbound traffic bawat buwan. Saklaw na ito ng pinakamaliliit na plan, kaya basahin ang aktuwal na buwanang gastos ng maliit na VPS bago pumili ng mas malaking kapasidad.

Maliit ang abuse surface, at ito ang bahaging madalas napagkakamalan. Ang bridge ang unang hop. Ang traffic na umaalis sa server mo ay pumupunta sa ibang Tor relay, hindi sa website na pinili ng user. Hindi kailanman lumalabas ang IP address mo sa web log ng ibang tao bilang source ng request. Kaya hindi rito dumarating ang complaint mail na hinahandle ng mga operator ng exit relay. Suriin pa rin ang acceptable use policy ng provider mo, dahil itinuturing ng ilang host na special case ang anumang Tor service. Magkatulad ngunit magkasalungat ang bridge at onion service sa ganitong punto: kapaki-pakinabang ang bridge dahil reachable ang address nito at kalaunan ay ipinamamahagi, samantalang kapaki-pakinabang lamang ang v3 onion service sa kaparehong uri ng VPS habang hindi nakikita ang public IP mo.

May isang bagay na hindi dapat gawin: gawing bridge ang dati nang public relay sa parehong address. Ayon sa payo ng Tor Project para sa sitwasyong ito, palitan ang “IP address, name and fingerprint”, dahil nasa consensus na dina-download ng mga censor ang lumang address. Ang bridge na public relay noong nakaraang linggo ay bridge na nasa blocklist na.

Mas mahalaga ang uptime kaysa speed. Nakasaad sa relay requirements na “if your relay is not running for more than 2 hours a day its usefulness is limited”. Mas mahina ang posisyon ng bridge kaysa relay sa puntong ito, dahil iisa lamang ang address ng bawat client at walang fallback. Kapag nag-restart ito, mawawala ang koneksyon ng bawat user dito. Mag-set up ng TCP port check sa Uptime Kuma laban sa obfs4 port para malaman mo agad kung kailan ito tumigil sa pagtugon.

I-install ang Tor mula sa repository ng Tor Project

Luma na ang mga package ng distribution, at ang bridge ay security software na dapat napapanahon. Idagdag muna ang sariling repository ng project.

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

Ngayon, isulat ang source file. Dapat taglay ng Suites: line ang release codename mo, kaya basahin ito mula sa system sa halip na hulaan mula sa memorya.

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

Kung iniulat ng apt update na walang Release file ang repository para sa iyong codename, hindi sinusuportahan ng Tor Project ang release na iyon. Tanggalin ang /etc/apt/sources.list.d/tor.sources, patakbuhin muli ang sudo apt update, at i-install ang tor package na ibinibigay ng iyong distribution. Pareho ang lahat ng kasunod na hakbang.

Ang obfs4proxy package ay mula mismo sa Debian at Ubuntu (version 0.0.14 sa Debian 13, noong Agosto 2026). Tiyakin kung saan nailagay ang binary, dahil ilalagay ang path nito sa config:

command -v obfs4proxy || command -v lyrebird

Pinalitan ng upstream ang pangalan ng project at ginawa itong lyrebird, kaya maaaring /usr/bin/lyrebird ang i-install ng mas bagong package. Gamitin ang path na ilalabas ng command na iyon.

I-configure ang bridge sa /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

May nakatalang posibleng failure sa bawat linya, kaya isa-isahin ang mga ito.

Sinasabi ng BridgeRelay 1 sa tor na ipadala ang descriptor nito sa bridge authority sa halip na sa public consensus. Ang nag-iisang linyang ito ang dahilan kung bakit hindi nakalista ang relay.

Ang ORPort ang aktuwal na Tor port. Dapat itong maabot mula sa internet dahil sinusuri ito ng tor at tumatangging mag-publish ng descriptor hangga't hindi pumapasa ang pagsusuring iyon.

Ibinibigay ng ServerTransportPlugin sa tor ang command na dapat nitong patakbuhin. Sinisimulan ng tor ang obfs4proxy bilang child process at nakikipag-ugnayan dito sa pamamagitan ng pipe. Dahil dito, walang sarili nitong service unit ang obfs4proxy at hindi ito lumalabas sa systemctl status.

Itinatakda ng ServerTransportListenAddr ang port na pakikinggan ng obfs4proxy. Kung aalisin mo ang linyang ito, pipili ang obfs4proxy ng libreng port sa startup at kadalasang ibang port ito pagkatapos ng restart. Dahil dito, ituturo ng bawat bridge line na naibigay mo na ang mga client sa port na walang nakikinig. Makakakuha ang mga client na iyon ng refused connection at titigil sa muling pagsubok.

Binubuksan ng ExtORPort auto ang extended ORPort, isang loopback channel na ginagamit ng obfs4proxy upang ibalik sa tor ang mga nakumpletong connection kasama ang address ng client. Isinasama ito ng setup guide ng Tor Project sa bawat bridge dahil kung wala ito, hindi maipapaalam ng transport sa tor ang address na iyon.

Parehong public ang ContactInfo at Nickname. Gumamit ng address na mababasa mo dahil dito ka kokontakin ng Tor Project kapag may sirang bridge. Pumili rin ng nickname na hindi magbubunyag ng iyong pagkakakilanlan kung mas gusto mong manatiling hindi napapansin.

Pinipili ng BridgeDistribution kung aling distributor ang magbibigay ng iyong address sa mga user. Ang mga tinatanggap na value ay https, email, telegram, settings, none at any. Gamitin ang any para sa unang bridge at hayaan ang system ang magpasya. Gamitin ang none para sa private bridge na ikaw mismo ang mamimigay. Sa ganitong paraan, mananatiling wala ang address sa public distribution.

Bakit mahalaga ang pagpili ng port

Iwasang gamitin ang 9001 para sa parehong port. Direktang sinasabi ito ng Tor Project dahil ang 9001 ang tradisyonal na ORPort, at ini-scan ito ng mga censor sa internet. Dapat magkaiba rin ang dalawang port dahil sariling listener ang bina-bind ng tor at obfs4proxy.

Ang pinakamainam na obfs4 port ay 443. Bukas ang outbound 443 sa halos lahat ng restricted network, at ang matagalang connection dito ay kahawig ng karaniwang web session. Ang pag-bind sa port na mas mababa sa 1024 ay nangangailangan ng isang karagdagang hakbang dahil hindi tumatakbo bilang root ang obfs4proxy:

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

Idagdag ang dalawang linyang ito sa bawat editor na magbubukas:

[Service]
NoNewPrivileges=no

Hindi sapat ang capability lamang. Pinipigilan ng systemd na NoNewPrivileges ang isang proseso na magkaroon ng privilege na wala sa parent nito, at eksaktong ganoon ang file capability. Dahil dito, hindi ma-bind ng obfs4proxy ang 443 habang naka-enable ang setting.

Kung gusto mong laktawan ang hakbang na iyon, pumili ng ordinaryong high port at itala ito. Anuman ang piliin mo, huwag nang baguhin ang obfs4 port. Pinag-uugnay ng bridge line ang address, port, fingerprint, at certificate, kaya masisira agad ang bawat kopyang nasa browser na ng user kapag nagbago ang port.

Buksan ang mga port sa parehong firewall

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

Kailangang bukas ang parehong port. Karamihan sa mga provider ay nagpapatakbo rin ng pangalawang firewall sa kanilang control panel na walang alam ang ufw. Ang rule na nasa server ngunit wala sa panel ay lumilikha ng bridge na hindi kailanman maaabot at hindi kailanman magpa-publish ng descriptor. Kung bago sa iyo ang alinman sa dalawang bahaging ito, saklaw ng mga ufw rule na kailangan ng bagong VPS at kung ano talaga ang listening port sa Linux ang mga ito. Habang ginagawa mo iyon, i-lock down ang SSH gamit ang mga key at pinatibay na sshd config. Ang bridge na hindi nakalista sa server na gumagamit ng password para sa SSH ay server pa ring gumagamit ng password para sa SSH.

Simulan ito, pagkatapos basahin ang log

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

May dalawang unit ang Debian at Ubuntu. Ang tor.service ay isang maliit na wrapper, at ang tor@default.service ang prosesong gumagawa ng aktuwal na trabaho. Kaya halos walang laman ang journalctl -u tor, samantalang nasa ilalim ng tor@default ang log na kailangan mo.

Dalawang linya ang nagpapatunay na gumana ito:

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

Ibig sabihin ng una, pumasa ang reachability test at naipasa ang descriptor sa bridge authority. Kung hindi ito kailanman lumitaw, may bahagi sa pagitan ng internet at ng server mo na nagda-drop ng traffic papunta sa ORPort. Dapat ipakita ng ikalawang linya ang port na iyong na-configure. Kung ibang port ang lumitaw roon, hindi inilapat ni tor ang ServerTransportListenAddr. Karaniwang sanhi nito ang hindi magkatugmang transport name: dapat obfs4 ang nakalagay sa parehong directive.

Kumpirmahing umiiral ang dalawang listener:

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

Nasaan ang bridge line ko?

Nagsusulat ang obfs4proxy ng template sa data directory ng tor:

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

Pagmamay-ari ng tor user ang directory na iyon at mode 700 ito. Kaya kung wala ang sudo, makukuha mo ang Permission denied. May line ang file na ganito ang format:

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

Palitan ang <IP ADDRESS> ng public address ng server mo, ang <PORT> ng obfs4 port at hindi ng ORPort, at ang <FINGERPRINT> ng identity fingerprint na isinulat ng tor sa data directory nito:

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

Nasa unang file ang nickname mo at ang identity fingerprint na dapat ilagay sa bridge line. Nasa pangalawang file ang hashed fingerprint. Ito ang i-paste mo sa Relay Search para malaman kung tumatakbo ang bridge mo at tinatayang ilang client ang kumokonekta rito. Hindi maaaring pagpalitin ang dalawang ito. Kapag hashed value ang nasa bridge line, hindi ito tumutugma sa identity key na ipinapakita ng bridge mo. Dahil dito, nire-reject ng client ang connection na kakabukas lang nito.

Paano talaga naaabot ng bridge ang mga user?

Hindi mo ipinapamigay ang bridge line sa kahit kanino. Kapag nakarating na ang descriptor sa bridge authority, itinatalaga ng distribution system (rdsys, ang pumalit sa BridgeDB) ang bridge mo sa isang distributor. Humihingi naman ang mga user ng bridges sa distributor na iyon. Noong August 2026, ito ang mga route:

• Ang web form sa bridges.torproject.org/options, na naghahatid ng bridge lines matapos ang captcha.
• Email sa bridges@torproject.org mula sa Gmail o Riseup address, na tumutugon gamit ang bridge lines. May restriction sa provider dahil maaaring gamitin ang walang limitasyong libreng account upang ma-enumerate ng isang censor ang bawat bridge.
• Ang Telegram bot na @GetBridgesBot. Ipadala ang /start, pagkatapos ay ang /obfs4 o /webtunnel.
• Ang Tor Browser mismo, sa Settings at pagkatapos ay Connection, kung saan kinukuha ng "Request bridges" ang mga ito sa pamamagitan ng moat channel.

Lumalabas ang bagong bridge sa Relay Search mga tatlong oras matapos itong i-setup. Mas matagal bago may mga user: ayon sa mismong pahayag ng Tor Project, "Maaaring lumipas ang ilang araw o linggo bago ka makakita ng pare-parehong set ng mga user." Normal ang tahimik na unang dalawang linggo. Hindi ito indikasyon ng problema.

Ang pag-set ng BridgeDistribution none ay nag-o-opt out sa lahat ng ito. Ikaw na ang magpapadala ng bridge line sa mga taong nangangailangan nito, gamit ang channel na hindi binabasa ng censor.

Kapag may hindi gumagana

Walang self-testing line sa log. Hindi naaabot ang ORPort. Subukan ito mula sa ibang machine gamit ang nc -vz your.ip 8443. Kapag nag-hang, nangangahulugan itong dina-drop ang mga packet, kaya suriin ang ufw at ang panel ng provider. Kapag may refusal, nangangahulugan itong hindi nakikinig ang tor, kaya suriin ang ss -lntp at basahin ang log para sa config error.

May port na hindi mo pinili ang nakalista sa registered transport. Hindi pinansin ng tor ang ServerTransportListenAddr. Kailangang eksaktong tumugma ang transport name sa nasa ServerTransportPlugin, at kailangang obfs4 ang dalawa.

Hindi ma-bind ng obfs4proxy ang port 443. Kumpirmahin ang capability gamit ang getcap /usr/bin/obfs4proxy, pagkatapos ay tiyaking nakarating ang override sa unit gamit ang systemctl show tor@default -p NoNewPrivileges. Kung NoNewPrivileges=yes ang output, nailagay ang drop-in sa unit na hindi tumatakbo.

Walang laman sa loob ng /var/lib/tor/pt_state/. Hindi sinimulan ng tor ang transport, kaya mali ang path sa ServerTransportPlugin. Ihambing ito sa output ng command -v obfs4proxy.

Tumigil ang mga client sa pagkonekta matapos ang isang pagbabago. Anumang pagbabago sa address o obfs4 port ay nagpapawalang-bisa sa lahat ng bridge line na naipamahagi na. Suriin kung nagbago rin ang public IP ng server. Nangyayari ito sa rebuild sa ilang provider.

Hindi talaga nagsisimula ang tor. Patakbuhin ang sudo -u debian-tor tor --verify-config -f /etc/tor/torrc. Ipa-parse nito ang file, ipi-print ang line na may error, at hindi gagalawin ang kasalukuyang tumatakbong service.

FAQ

Magrereklamo ba ang VPS provider ko tungkol sa Tor bridge?

Ang bridge ay isang entry point, kaya ang traffic na lumalabas sa server mo ay pumupunta sa iba pang Tor relay at hindi direkta sa site na pinili ng user. Hindi lumilitaw ang IP address mo sa web log ng sinuman bilang pinagmulan ng request. Iyan ang sanhi ng mga reklamong hinaharap ng mga operator ng exit relay. Nagkakaiba pa rin ang hosting rules, at itinuturing ng ilang provider na espesyal na kaso ang anumang Tor service. Basahin ang acceptable use policy bago ka magsimula at ilagay sa ContactInfo ang address na nabasa mo.

Gaano karaming bandwidth ang ginagamit ng Tor bridge?

Ang published minimum ay 1 Mbit/s para sa upload at download, kumpara sa 10 Mbit/s para sa guard o middle relay. Karaniwang nagsisimula sa halos zero ang aktuwal na paggamit, dahil ang bridge mo ay nagdadala lamang ng traffic para sa mga user na ipinapadala rito ng isang distributor. Kung gusto mo ng mahigpit na upper limit, itakda ang RelayBandwidthRate at RelayBandwidthBurst sa torrc.

Bakit walang kumokonekta sa bago kong bridge?

Tumatagal nang humigit-kumulang tatlong oras bago lumitaw ang bridge sa Relay Search. Ayon sa gabay ng Tor Project, tumatagal naman ng ilang araw o linggo bago magkaroon ng tuloy-tuloy na grupo ng mga user. Tiyaking na-publish ang descriptor, na siyang self-testing line sa journalctl -u tor@default. Hanapin ang hashed fingerprint mo sa Relay Search at tiyaking hindi nakatakda ang BridgeDistribution sa none.

Dapat ko bang patakbuhin ang obfs4 o WebTunnel?

Patakbuhin ang obfs4 kung ito ang una mong bridge: isang VPS, dalawang port, walang domain, at walang certificate. Gamitin ang WebTunnel kung bina-block mismo ang traffic na mukhang random, dahil kailangan nito ng domain na kontrolado mo, isang totoong web server, valid na TLS certificate, at hindi bababa sa 1 GB ng RAM. Ilagay ang mga ito sa magkahiwalay na address kung pareho mong patatakbuhin, dahil kung hindi, isang blocked IP lang ang maaaring magpatigil sa dalawang bridge nang sabay.

Ano ang mangyayari kung babaguhin ko ang obfs4 port paglaon?

Hihinto sa paggana ang bawat bridge line na naipamahagi na. Itinatakda ng bridge line nang magkakasama ang address, port, fingerprint, at certificate. Kaya ang client na may hawak ng lumang line ay susubukang kumonekta sa port na walang nakikinig at susuko. Ganito rin ang mangyayari kapag nagbago ang public IP ng server. Piliin ang port habang nagse-set up at huwag na itong baguhin.