Paano Magpatakbo ng Tor Bridge na may obfs4 sa VPS

Ano ang Tor bridge at kung bakit ito umiiral

Ang Tor bridge ay isang entry point papunta sa Tor network na hindi inilalathala ang address nito sa public relay list. Ang listahang iyon, na tinatawag na consensus, ay isang signed document na maaaring i-download ng kahit sino, pati ng censor. Madaling i-block ang Tor gamit ito: i-fetch ang consensus, pagkatapos ay i-drop sa border ang bawat address na nakalista rito. Umiiral ang bridges dahil ang published list ang mahinang punto. Ibinibigay ang mga bridge address nang paisa-isa o kakaunti lamang, kaya walang isang request na naglalabas ng buong set.

Kalahati lamang ng solusyon ang isang unlisted address. Ang deep packet inspection (DPI), na nagka-classify ng traffic batay sa content nito sa halip na sa address, ay kumikilala sa Tor connection mula sa pattern 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. Inaalis ng pluggable transport ang signal na iyon. Binabalot nito ang Tor stream sa ibang anyo sa client side, at ina-unpack ito ng bridge mo.

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

Aling 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 puwedeng 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: 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 mismo ang traffic na mukhang random, dahil pinapahintulutan pa rin ng bansang halos naglilimita sa web browsing ang HTTPS.
• Ibang uri ng ambag ang Snowflake. Nagpapatakbo ang mga volunteer ng panandaliang WebRTC proxy, kaya palaging nagbabago ang mga entry point at walang stable address na maaaring i-block ng censor. Hindi ka nagpapatakbo ng bridge para rito. Proxy ang pinapatakbo mo, at hindi ito nangangailangan ng fixed address.

Magsimula sa obfs4. Maaari kang magdagdag ng WebTunnel bridge sa ibang pagkakataon, sa pangalawang address: kapag pareho silang tumatakbo sa iisang IP, sapat na ang pag-block sa isang address upang parehong maapektuhan ang mga ito.

Ano ang kapalit 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 measurement. 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. Kaya saklaw na ito ng pinakamaliliit na plan. Basahin ang aktuwal na buwanang gastos ng maliit na VPS bago pumili ng mas malaking setup.

Maliit ang abuse surface, at ito ang bahaging madalas napagkakamalan. Ang bridge ang unang hop. Ang traffic na lumalabas sa server mo ay pumupunta sa isa pang 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 pinangangasiwaan 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.

May isang bagay na hindi dapat gawin: gawing bridge ang isang kasalukuyang public relay habang pareho pa rin ang address. Ayon sa payo ng Tor Project para sa sitwasyong ito, palitan ang "IP address, name and fingerprint", dahil kasama na ang lumang address sa consensus na dina-download ng mga censor. 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 dehado rito ang bridge kaysa relay, dahil iisa ang address ng bawat client at walang fallback. Kapag nag-restart ito, mawawala ang koneksyon ng bawat user na nakakonekta rito. Mag-set up ng TCP port check sa Uptime Kuma laban sa obfs4 port para malaman mo sa araw ding tumigil itong sumagot.

I-install ang Tor mula sa Tor Project repository

Nahuhuli ang mga package ng distribution sa mga release, at ang bridge ay security software na dapat napapanahon. Idagdag muna ang sariling repository ng proyekto.

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 ilaman ng Suites: line ang release codename mo, kaya kunin 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 codename mo, hindi sinusuportahan ng Tor Project ang release na iyon. Burahin 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 nasa ibaba.

Ang obfs4proxy package ay mula mismo sa Debian at Ubuntu (version 0.0.14 sa Debian 13, noong August 2026). Kumpirmahin kung saan na-install ang binary, dahil ilalagay ang path nito sa config:

command -v obfs4proxy || command -v lyrebird

Pinalitan ng upstream ang pangalan ng proyekto ng 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 kaukulang failure ang bawat linyang iyon, 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 tine-test ito ng tor at tumatangging mag-publish ng descriptor hanggang hindi pumapasa ang test.

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

Itinatakda ng ServerTransportListenAddr ang port na pakikinggan ng obfs4proxy. Kapag iniwan mo ang linyang ito, pipili ang obfs4proxy ng available na port sa startup. Karaniwan, iba ang napipili pagkatapos ng bawat restart. Dahil dito, ang bawat bridge line na naibigay mo na ay tumuturo sa port na walang nakikinig. Makakatanggap ang mga client na iyon ng refused connection at hihinto sa pag-try.

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

Parehong public ang ContactInfo at Nickname. Gumamit ng address na regular mong mababasa dahil dito ka kokontakin ng Tor Project tungkol sa bridge na may problema. Pumili rin ng nickname na hindi makakapagpakilala sa iyo kung mas gusto mong manatiling tahimik.

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, hindi naisasama 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 sini-scan ito ng mga censor sa internet. Dapat magkaiba rin ang dalawang port dahil ang tor at obfs4proxy ay parehong nagbi-bind sa sarili nilang listener.

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

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 nang mag-isa. Pinipigilan ng systemd na NoNewPrivileges ang isang process na magkaroon ng privilege na wala sa parent nito, at ganoon mismo ang file capability. Dahil dito, hindi makapag-bind ang obfs4proxy sa 443 habang naka-enable ang setting.

Kung mas 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 sa ibang pagkakataon. Pinagkakabit ng bridge line ang address, port, fingerprint, at certificate, kaya masisira agad ang bawat kopyang nasa browser na ng user kapag inilipat 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 may ikalawang firewall sa kanilang control panel na walang kaalaman ang ufw. Ang rule na umiiral sa server ngunit wala sa panel ay nagreresulta sa 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 ibig sabihin ng listening port sa Linux ang mga ito. Habang ginagawa mo ito, i-lock down ang SSH gamit ang mga key at hardened na sshd config. Ang bridge na hindi naka-lista sa server na gumagamit ng password sa SSH ay server pa rin na gumagamit ng password 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 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, nagtagumpay ang reachability test at naipadala ang descriptor sa bridge authority. Kung hindi ito lumitaw, may bahagi sa pagitan ng internet at ng server mo na nagba-block ng traffic papunta sa ORPort. Dapat ipakita ng ikalawang linya ang port na iyong na-configure. Kung ibang port ang nakalagay, hindi inilapat ng tor ang ServerTransportListenAddr. Karaniwang sanhi nito ang hindi magkatugmang transport name: dapat obfs4 ang nakalagay sa dalawang 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 kapag wala ang sudo, makakakuha ka ng 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 ikalawang file ang hashed fingerprint. Ito ang ilalagay mo sa Relay Search para makita kung tumatakbo ang bridge mo at ang tinatayang bilang ng mga client na kumokonekta rito. Hindi maaaring pagpalitin ang dalawang ito. Kapag hashed value ang nasa bridge line, hindi ito tutugma sa identity key na ipinapakita ng bridge mo, kaya nire-reject ng client ang kakabukas pa lamang nitong connection.

Paano talaga nakararating sa mga user ang bridge?

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, at humihingi ang mga user ng bridges sa distributor na iyon. Noong August 2026, ito ang mga ruta:

• Ang web form sa bridges.torproject.org/options, na naghahatid ng bridge lines pagkatapos ng captcha.
• Email sa bridges@torproject.org mula sa Gmail o Riseup address, na sumasagot gamit ang bridge lines. May ganitong restriction sa provider dahil maaaring gamitin ang walang limitasyong free accounts para ma-enumerate ng isang censor ang lahat ng 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 pagkalipas ng humigit-kumulang tatlong oras mula nang i-setup ito. Mas matagal bago ito makita ng 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 kaunting user sa unang dalawang linggo. Hindi ito nangangahulugang may sira.

Kapag itinakda mo ang BridgeDistribution none, hindi ka kasali sa lahat ng pamamaraang 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 reachable ang ORPort. I-test ito mula sa ibang machine gamit ang nc -vz your.ip 8443. Kapag nag-hang, ibig sabihin ay dini-drop ang mga packet, kaya suriin ang ufw at ang panel ng provider. Kapag may refusal, ibig sabihin ay hindi nakikinig ang tor, kaya suriin ang ss -lntp at basahin ang log para sa config error.

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

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

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

Tumigil sa pagkonekta ang mga client 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 gamit ang ilang provider.

Hindi talaga nag-start ang tor. Patakbuhin ang sudo -u debian-tor tor --verify-config -f /etc/tor/torrc. Ipa-parse nito ang file, ipi-print ang linyang tinututulan nito, at hindi nito gagalawin ang tumatakbong service.

FAQ

Magrereklamo ba ang VPS provider ko tungkol sa Tor bridge?

Ang bridge ay 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 lumalabas ang IP address mo sa web log ng sinuman bilang source ng request. Iyan ang pinagmumulan 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 inilathalang minimum ay 1 Mbit/s para sa upload at download, kumpara sa 10 Mbit/s para sa guard o middle relay. Karaniwang halos zero ang aktuwal na paggamit sa simula, dahil traffic lamang ng mga user na ipinapadala rito ng distributor ang dinadala ng bridge mo. Kung gusto mo ng mahigpit na limitasyon, itakda ang RelayBandwidthRate at RelayBandwidthBurst sa torrc.

Bakit walang kumokonekta sa bago kong bridge?

Umaabot ng humigit-kumulang tatlong oras bago lumitaw ang bridge sa Relay Search. Ayon sa gabay ng Tor Project, umaabot naman ng ilang araw o linggo bago magkaroon ng tuloy-tuloy na hanay ng mga user. Suriin kung 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 ba akong gumamit ng obfs4 o WebTunnel?

Gumamit ng obfs4 kung ito ang una mong bridge: isang VPS, dalawang port, walang domain, at walang certificate. Gamitin ang WebTunnel kapag bina-block mismo ang traffic na mukhang random, dahil kailangan nito ng domain na kontrolado mo, aktuwal na web server, valid na TLS certificate, at hindi bababa sa 1 GB ng RAM. Ilagay ang mga ito sa magkahiwalay na address kung gagamitin mo pareho, dahil kung hindi, dalawang bridge ang mawawala kapag na-block ang isang IP.

Ano ang mangyayari kung babaguhin ko ang obfs4 port sa susunod?

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