วิธีตั้งค่า Tor bridge ด้วย obfs4 บน VPS อย่างละเอียด

Tor bridge คืออะไรและทำไมจึงต้องมี

Tor bridge คือจุดเชื่อมต่อเข้าสู่เครือข่าย Tor ที่ไม่มีการประกาศที่อยู่ไว้ในรายการ relay สาธารณะ รายการดังกล่าวที่เรียกว่า consensus เป็นเอกสารที่มีการลงลายมือชื่อซึ่งใครก็สามารถดาวน์โหลดได้ และผู้เซ็นเซอร์ก็ดาวน์โหลดได้เช่นกัน การบล็อก Tor จากรายการนี้ใช้เวลาเพียงช่วงบ่าย: เพียงแค่ดึงข้อมูล consensus มา แล้วทำการดร็อปทุกที่อยู่ที่อยู่ในนั้นที่เกตเวย์เครือข่าย สาเหตุที่มี bridge ก็เพราะรายการที่ประกาศไว้นี้เป็นจุดอ่อน ที่อยู่ของ bridge จะถูกแจกจ่ายออกไปทีละน้อย ดังนั้นการร้องขอเพียงครั้งเดียวจึงไม่สามารถดึงข้อมูลทั้งหมดไปได้

ที่อยู่ที่ไม่ได้อยู่ในรายการเป็นเพียงคำตอบครึ่งเดียวเท่านั้น การตรวจสอบแพ็กเก็ตเชิงลึก (Deep packet inspection หรือ DPI) ซึ่งจำแนกประเภททราฟฟิกตามเนื้อหาแทนที่จะเป็นที่อยู่ สามารถตรวจจับการเชื่อมต่อ Tor ได้จากรูปแบบของ TLS (transport layer security) handshake ผู้เซ็นเซอร์ที่ไม่มีรายการที่อยู่ก็ยังสามารถมองเห็นได้ว่า "นี่ดูเหมือน Tor" แล้วทำการดร็อปการเชื่อมต่อทิ้งไป Pluggable transport จะช่วยกำจัดสัญญาณดังกล่าว โดยจะทำการห่อหุ้มสตรีมของ Tor ไว้ด้วยรูปแบบอื่นที่ฝั่งไคลเอนต์ และ bridge ของคุณจะทำหน้าที่แกะห่อหุ้มนั้นออก

obfs4 เป็น transport ที่ bridge ส่วนใหญ่ใช้งาน มันจะเปลี่ยนสตรีมให้กลายเป็นชุดไบต์ที่ไม่มี header และไม่มี handshake ที่ตายตัว ทำให้ DPI ไม่มีรูปแบบให้ตรวจจับได้ นอกจากนี้ยังมีการยืนยันตัวตนของไคลเอนต์ด้วย ค่า cert= ที่อยู่ในบรรทัดของ bridge คือกุญแจที่ไคลเอนต์ต้องพิสูจน์ว่าตนถือครองอยู่ก่อนที่ bridge จะตอบสนองใดๆ ซึ่งช่วยป้องกันการตรวจสอบเชิงรุก (active probing): ผู้เซ็นเซอร์ที่พยายามเชื่อมต่อเข้ามายังที่อยู่ของคุณเพื่อทดสอบว่ามันสื่อสารด้วยโปรโตคอล Tor หรือไม่ จะไม่ได้รับคำตอบใดๆ และไม่สามารถเรียนรู้อะไรได้เลย

คุณควรใช้งาน Pluggable Transport แบบใด?

• obfs4 ต้องใช้ VPS 1 เครื่อง, TCP port 2 พอร์ต และไม่ต้องใช้ชื่อโดเมน นี่เป็นสิ่งที่ใช้งานได้จริงและง่ายที่สุดที่คุณสามารถทำได้ และเป็นหัวข้อหลักของคู่มือนี้
• WebTunnel จะซ่อนการเชื่อมต่อไว้ภายในทราฟฟิก HTTPS ปกติที่ไปยังเว็บไซต์จริง Tor Project ระบุข้อกำหนดไว้ว่าต้องมี IPv4 address แบบ static, โดเมนที่คุณเป็นเจ้าของ, เว็บเซิร์ฟเวอร์ที่ทำงานได้ปกติ เช่น NGINX หรือ Apache, ใบรับรอง TLS ที่ถูกต้อง และ RAM อย่างน้อย 1 GB (แนะนำที่ 4 GB) วิธีนี้เหมาะสำหรับเครือข่ายที่ทราฟฟิกซึ่งดูผิดปกติจะถูกเพ่งเล็งเป็นพิเศษ เนื่องจากประเทศที่อนุญาตให้เข้าถึงได้เพียงแค่การท่องเว็บทั่วไป ก็ยังคงอนุญาตให้ใช้งาน HTTPS ได้
• Snowflake เป็นการสนับสนุนในรูปแบบที่ต่างออกไป อาสาสมัครจะรัน WebRTC proxy แบบชั่วคราว ทำให้จุดเชื่อมต่อเปลี่ยนไปเรื่อยๆ และไม่มีที่อยู่คงที่ให้ผู้เซ็นเซอร์บล็อก คุณไม่จำเป็นต้องดูแล Bridge สำหรับ Snowflake คุณเพียงแค่รัน Proxy ซึ่งไม่จำเป็นต้องใช้ที่อยู่คงที่

ให้เริ่มต้นด้วย obfs4 คุณสามารถเพิ่ม 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 ทาง Tor Project กำหนดให้ bridge ต้องมีแบนด์วิดท์ขาขึ้นและขาลงอย่างน้อย 1 Mbit/s สำหรับ guard หรือ middle relay จะถูกกำหนดไว้ที่ 10 Mbit/s โดยแนะนำให้ใช้ที่ 16 Mbit/s ข้อกำหนดเหล่านี้เป็นค่าที่ประกาศไว้ ไม่ใช่ค่าที่วัดผลจริง โดยปกติแล้ว bridge ใหม่มักจะมีปริมาณการใช้งานต่ำกว่าเกณฑ์ขั้นต่ำเป็นเวลาหลายสัปดาห์ หน้าข้อกำหนดเดียวกันระบุว่า relay ควรมีปริมาณการรับส่งข้อมูลขาออกอย่างน้อย 100 GByte ต่อเดือน ซึ่งแพ็กเกจขนาดเล็กที่สุดก็ครอบคลุมส่วนนี้อยู่แล้ว ดังนั้นโปรดอ่าน ค่าใช้จ่ายจริงต่อเดือนของ VPS ขนาดเล็ก ก่อนที่คุณจะเลือกขนาดที่ใหญ่กว่านี้

ความเสี่ยงจากการถูกร้องเรียนเรื่องการใช้งาน (abuse) นั้นต่ำ ซึ่งเป็นจุดที่คนส่วนใหญ่มักเข้าใจผิด bridge คือโหนดแรก (first hop) ของเส้นทาง ข้อมูลที่ออกจากเซิร์ฟเวอร์ของคุณจะถูกส่งต่อไปยัง Tor relay อื่น ไม่ใช่ไปยังเว็บไซต์ที่ผู้ใช้เลือกโดยตรง ดังนั้น IP address ของคุณจะไม่ปรากฏใน log ของเว็บไซต์ปลายทางในฐานะต้นทางของคำขอ ทำให้คุณจะไม่ได้รับอีเมลร้องเรียนแบบที่ผู้ดูแล exit relay ต้องเผชิญ อย่างไรก็ตาม ควรตรวจสอบนโยบายการใช้งานที่ยอมรับได้ (acceptable use policy) ของผู้ให้บริการของคุณไว้ด้วย เนื่องจากโฮสต์บางรายถือว่าบริการ Tor ทุกประเภทเป็นกรณีพิเศษ bridge และ onion service เปรียบเสมือนภาพสะท้อนของกันและกันในแง่นี้ bridge จะมีประโยชน์ก็ต่อเมื่อที่อยู่ของมันสามารถเข้าถึงได้และถูกแจกจ่ายออกไป ในขณะที่ v3 onion service บน VPS ประเภทเดียวกัน จะมีประโยชน์ก็ต่อเมื่อ IP สาธารณะของคุณยังคงถูกซ่อนไว้เท่านั้น

สิ่งที่ไม่ควรทำคือการเปลี่ยน public relay ที่มีอยู่เดิมให้เป็น bridge โดยใช้ที่อยู่เดิม คำแนะนำของ Tor Project สำหรับกรณีนี้คือให้เปลี่ยน "IP address, ชื่อ และ fingerprint" เนื่องจากที่อยู่เดิมนั้นอยู่ในรายการ consensus ที่ผู้เซ็นเซอร์ดาวน์โหลดไปใช้งานแล้ว bridge ที่เคยเป็น public relay เมื่อสัปดาห์ก่อน คือ bridge ที่อยู่ในรายการบล็อกเรียบร้อยแล้ว

ความต่อเนื่องในการทำงาน (uptime) สำคัญกว่าความเร็ว ข้อกำหนดของ relay ระบุว่า "หาก relay ของคุณไม่ทำงานเกิน 2 ชั่วโมงต่อวัน ประโยชน์ของมันจะลดลง" และ bridge จะได้รับผลกระทบมากกว่า relay เนื่องจากไคลเอนต์แต่ละรายมีที่อยู่เพียงที่เดียวและไม่มีช่องทางสำรอง การรีสตาร์ทจะทำให้ผู้ใช้ทุกคนที่เชื่อมต่ออยู่หลุดทันที ควรตั้งค่า การตรวจสอบ TCP port ใน Uptime Kuma สำหรับพอร์ต obfs4 เพื่อให้คุณทราบทันทีในวันที่มันหยุดตอบสนอง

การติดตั้ง Tor จาก repository ของ Tor Project

แพ็กเกจใน distribution มักจะล้าสมัย และ bridge เป็นซอฟต์แวร์ด้านความปลอดภัยที่ควรเป็นเวอร์ชันล่าสุดเสมอ ให้เพิ่ม repository ของโครงการโดยตรงก่อน

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

จากนั้นให้เขียนไฟล์ source โดยบรรทัด Suites: จะต้องระบุ codename ของ release ที่คุณใช้งานอยู่ ดังนั้นให้อ่านค่าจากระบบแทนการพิมพ์เองจากความจำ

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 รายงานว่า repository ไม่มีไฟล์ Release สำหรับ codename ของคุณ แสดงว่า Tor Project ไม่รองรับ release นั้น ให้ลบ /etc/apt/sources.list.d/tor.sources แล้วรัน sudo apt update อีกครั้ง จากนั้นติดตั้งแพ็กเกจ tor ที่มากับ distribution ของคุณแทน ขั้นตอนหลังจากนี้จะเหมือนกันทั้งหมด

แพ็กเกจ obfs4proxy มาจาก Debian และ Ubuntu โดยตรง (เวอร์ชัน 0.0.14 ใน Debian 13 ณ เดือนสิงหาคม 2026) ให้ตรวจสอบว่า binary ถูกติดตั้งไว้ที่ใด เนื่องจากต้องนำ path ไปใส่ในไฟล์ config:

command -v obfs4proxy || command -v lyrebird

ทางต้นน้ำได้เปลี่ยนชื่อโครงการเป็น lyrebird ดังนั้นแพ็กเกจที่ใหม่กว่าอาจติดตั้ง /usr/bin/lyrebird แทน ให้ใช้ path ใดก็ตามที่คำสั่งดังกล่าวแสดงผลออกมา

กำหนดค่า bridge ใน /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 ส่ง descriptor ไปยัง bridge authority แทนที่จะส่งไปยัง public consensus บรรทัดนี้เพียงบรรทัดเดียวคือสิ่งที่ทำให้ relay ของคุณไม่ปรากฏในรายการสาธารณะ

ORPort คือพอร์ต Tor จริง พอร์ตนี้ต้องสามารถเข้าถึงได้จากอินเทอร์เน็ต เนื่องจาก tor จะทำการทดสอบและปฏิเสธที่จะเผยแพร่ descriptor จนกว่าการทดสอบนั้นจะผ่าน

ServerTransportPlugin คือคำสั่งที่ให้ tor เรียกใช้งาน tor จะเริ่มการทำงานของ obfs4proxy ในฐานะ child process และสื่อสารผ่าน pipe ดังนั้น obfs4proxy จึงไม่มี service unit ของตัวเองและจะไม่ปรากฏใน systemctl status

ServerTransportListenAddr กำหนดพอร์ตที่ obfs4proxy จะรับฟัง หากละเว้นบรรทัดนี้ obfs4proxy จะสุ่มเลือกพอร์ตว่างเมื่อเริ่มทำงาน และอาจเปลี่ยนพอร์ตใหม่หลังการรีสตาร์ทส่วนใหญ่ ส่งผลให้ bridge line ทุกบรรทัดที่คุณแจกจ่ายไปก่อนหน้านี้ชี้ไปยังพอร์ตที่ไม่มีการรับฟังข้อมูล ส่งผลให้ไคลเอนต์เหล่านั้นได้รับข้อผิดพลาดการเชื่อมต่อและหยุดพยายามเชื่อมต่อในที่สุด

ExtORPort auto เปิดใช้งาน extended ORPort ซึ่งเป็นช่องทาง loopback ที่ obfs4proxy ใช้ส่งต่อการเชื่อมต่อที่เสร็จสมบูรณ์กลับไปยัง tor พร้อมกับที่อยู่ของไคลเอนต์ คู่มือการตั้งค่าของ The Tor Project แนะนำให้ใส่บรรทัดนี้ไว้ใน bridge ทุกตัว เพราะหากไม่มีบรรทัดนี้ transport จะไม่สามารถรายงานที่อยู่ดังกล่าวไปยัง tor ได้

ContactInfo และ Nickname เป็นข้อมูลสาธารณะ ควรใช้ที่อยู่อีเมลที่คุณตรวจสอบเป็นประจำ เนื่องจากเป็นช่องทางที่ The Tor Project จะติดต่อคุณหาก bridge มีปัญหา และเลือกชื่อเล่นที่ไม่ระบุตัวตนของคุณหากคุณต้องการความเป็นส่วนตัว

BridgeDistribution เลือกตัวแทนจำหน่าย (distributor) ที่จะแจกจ่ายที่อยู่ของคุณให้กับผู้ใช้ ค่าที่ยอมรับได้คือ https, email, telegram, settings, none และ any ให้ใช้ any สำหรับ bridge ตัวแรกและปล่อยให้ระบบเป็นผู้ตัดสินใจ หรือใช้ none สำหรับ bridge ส่วนตัวที่คุณแจกจ่ายด้วยตนเอง ซึ่งจะช่วยป้องกันไม่ให้ที่อยู่ของคุณถูกนำไปเผยแพร่ในระบบสาธารณะโดยสิ้นเชิง

เหตุผลที่การเลือกพอร์ตมีความสำคัญ

หลีกเลี่ยงการใช้ 9001 สำหรับพอร์ตทั้งสองช่องทาง Tor Project ได้ระบุไว้โดยตรงว่า 9001 เป็นพอร์ต ORPort แบบดั้งเดิม ซึ่งผู้ตรวจเซ็นเซอร์มักสแกนหาพอร์ตนี้บนอินเทอร์เน็ต พอร์ตทั้งสองต้องไม่ซ้ำกันเนื่องจาก tor และ obfs4proxy ต่างก็ผูก listener ของตนเอง

พอร์ตสำหรับ 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) เพียงอย่างเดียวไม่เพียงพอ การตั้งค่า NoNewPrivileges ของ systemd จะป้องกันไม่ให้กระบวนการได้รับสิทธิ์ใดๆ ที่กระบวนการแม่ไม่มี และ file capability ก็ถือเป็นสิทธิ์ประเภทนั้น ส่งผลให้ obfs4proxy ไม่สามารถผูกพอร์ต 443 ได้หากยังเปิดการตั้งค่านี้ไว้

หากคุณต้องการข้ามขั้นตอนนี้ ให้เลือกพอร์ตสูงที่ไม่มีความโดดเด่นและจดบันทึกไว้ ไม่ว่าคุณจะเลือกพอร์ตใด ห้ามเปลี่ยนพอร์ต obfs4 ในภายหลัง เนื่องจาก bridge line จะผูกที่อยู่ พอร์ต fingerprint และ certificate เข้าด้วยกัน ดังนั้นทุกสำเนาที่อยู่ในเบราว์เซอร์ของผู้ใช้จะใช้งานไม่ได้ทันทีที่พอร์ตถูกเปลี่ยน

เปิดพอร์ตบนไฟร์วอลล์ทั้งสองฝั่ง

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

จำเป็นต้องเปิดพอร์ตทั้งสองพอร์ต ผู้ให้บริการส่วนใหญ่มีไฟร์วอลล์ชั้นที่สองในแผงควบคุม ซึ่ง ufw ไม่สามารถรับรู้ได้ กฎที่ตั้งค่าไว้ในเครื่องแต่ไม่ได้ตั้งค่าในแผงควบคุมจะทำให้เกิด bridge ที่ไม่สามารถเข้าถึงได้และไม่เผยแพร่ descriptor หากคุณยังไม่คุ้นเคยกับส่วนใดส่วนหนึ่ง กฎ ufw ที่ VPS ใหม่จำเป็นต้องมี และ พอร์ตที่กำลังฟังอยู่บน Linux คืออะไร จะช่วยอธิบายเรื่องนี้ ในระหว่างนั้น จำกัดสิทธิ์ SSH ด้วยคีย์และการตั้งค่า sshd ที่ปลอดภัย เพราะ bridge ที่ไม่ได้ระบุไว้ในเครื่องที่ใช้รหัสผ่าน SSH ก็ยังคงเป็นเครื่องที่ใช้รหัสผ่าน SSH อยู่ดี

เริ่มการทำงานแล้วอ่าน log

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

Debian และ Ubuntu มี unit ให้ใช้งาน 2 ตัว tor.service เป็น wrapper ขนาดเล็ก และ tor@default.service เป็นกระบวนการที่ทำหน้าที่ประมวลผลจริง นี่คือเหตุผลว่าทำไม journalctl -u tor ถึงดูเหมือนว่างเปล่า ในขณะที่ log ที่คุณต้องการจะอยู่ใน tor@default

มี 2 บรรทัดที่ระบุว่าการทำงานสำเร็จ:

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 แล้ว หากบรรทัดนี้ไม่ปรากฏขึ้น แสดงว่ามีบางอย่างระหว่างอินเทอร์เน็ตกับเซิร์ฟเวอร์ของคุณที่คอยบล็อก traffic ที่ส่งไปยัง ORPort บรรทัดที่สองต้องแสดงพอร์ตที่คุณกำหนดค่าไว้ หากพอร์ตที่แสดงแตกต่างออกไป แสดงว่า tor ไม่ได้นำ ServerTransportListenAddr ไปใช้งาน ซึ่งสาเหตุที่พบบ่อยคือชื่อ transport ไม่ตรงกัน โดยชื่อดังกล่าวจะต้องระบุเป็น 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> ด้วย identity fingerprint ที่ tor เขียนไว้ในไดเรกทอรีข้อมูลของคุณ:

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

ไฟล์แรกจะเก็บชื่อเล่นและ identity fingerprint ที่ต้องใช้ใน bridge line ส่วนไฟล์ที่สองจะเก็บ hashed fingerprint ซึ่งเป็นค่าที่คุณต้องนำไปวางใน Relay Search เพื่อตรวจสอบว่า bridge ของคุณกำลังทำงานอยู่หรือไม่ และมีไคลเอนต์เชื่อมต่อเข้ามาประมาณเท่าใด ทั้งสองค่านี้ไม่สามารถใช้แทนกันได้ หาก bridge line มีค่า hashed อยู่ จะไม่ตรงกับ identity key ที่ bridge ของคุณนำเสนอ ส่งผลให้ไคลเอนต์ปฏิเสธการเชื่อมต่อที่เพิ่งเปิดขึ้นมานั้น

บริดจ์เข้าถึงผู้ใช้งานได้อย่างไร

คุณไม่จำเป็นต้องส่ง bridge line ให้ใครด้วยตัวเอง เมื่อ descriptor ของคุณไปถึง bridge authority แล้ว ระบบการแจกจ่าย (rdsys ซึ่งเป็นระบบที่มาแทนที่ BridgeDB) จะกำหนดบริดจ์ของคุณให้กับผู้จัดจำหน่ายรายหนึ่ง และผู้ใช้งานจะร้องขอบริดจ์จากผู้จัดจำหน่ายรายนั้น ณ เดือนสิงหาคม 2026 เส้นทางการเข้าถึงมีดังนี้:

• เว็บฟอร์มที่ bridges.torproject.org/options ซึ่งจะแสดง bridge line หลังจากผ่านการตรวจสอบ captcha
• การส่งอีเมลไปที่ bridges@torproject.org จากบัญชี Gmail หรือ Riseup ซึ่งระบบจะตอบกลับด้วย bridge line ข้อจำกัดเรื่องผู้ให้บริการมีไว้เพื่อป้องกันไม่ให้ผู้เซ็นเซอร์ใช้บัญชีฟรีจำนวนมหาศาลในการไล่เก็บข้อมูลบริดจ์ทั้งหมด
• บอท Telegram ที่ @GetBridgesBot ให้ส่งข้อความ /start จากนั้นเลือก /obfs4 หรือ /webtunnel
• ตัว Tor Browser เอง ในเมนู Settings แล้วไปที่ Connection ซึ่งตัวเลือก "Request bridges" จะดึงข้อมูลผ่านช่องทาง moat

บริดจ์ใหม่จะปรากฏใน Relay Search หลังจากตั้งค่าไปแล้วประมาณสามชั่วโมง แต่สำหรับผู้ใช้งานนั้นต้องใช้เวลานานกว่ามาก โดยทาง Tor Project ระบุว่า "อาจต้องใช้เวลาหลายวันหรือหลายสัปดาห์กว่าที่คุณจะเห็นจำนวนผู้ใช้งานที่สม่ำเสมอ" การที่ช่วงสองสัปดาห์แรกเงียบเหงาถือเป็นเรื่องปกติ ไม่ใช่ความผิดพลาดของระบบ

การตั้งค่า BridgeDistribution none จะเป็นการยกเลิกการเข้าร่วมระบบแจกจ่ายทั้งหมด จากนั้น bridge line จะเป็นของคุณโดยสมบูรณ์ เพื่อให้คุณนำไปส่งต่อให้ผู้ที่ต้องการผ่านช่องทางที่ผู้เซ็นเซอร์ไม่ได้เฝ้าติดตามอยู่

เมื่อบางอย่างไม่ทำงาน

ไม่มีบรรทัดการทดสอบตัวเองใน log ORPort ไม่สามารถเข้าถึงได้ ให้ทดสอบจากเครื่องอื่นด้วย nc -vz your.ip 8443 หากค้างแสดงว่าแพ็กเก็ตถูกทิ้ง ให้ตรวจสอบ ufw และแผงควบคุมของผู้ให้บริการ หากถูกปฏิเสธแสดงว่า tor ไม่ได้เปิดฟังอยู่ ให้ตรวจสอบ ss -lntp และอ่าน log เพื่อหาข้อผิดพลาดในการตั้งค่า

Transport ที่ลงทะเบียนไว้แสดงพอร์ตที่คุณไม่ได้เลือก tor เพิกเฉยต่อ ServerTransportListenAddr ชื่อของ transport ต้องตรงกับที่ระบุใน ServerTransportPlugin ทุกประการ และทั้งคู่ต้องเป็น obfs4

obfs4proxy ไม่สามารถ bind พอร์ต 443 ได้ ยืนยันความสามารถด้วย getcap /usr/bin/obfs4proxy จากนั้นยืนยันว่าการ override ไปถึง unit แล้วด้วย systemctl show tor@default -p NoNewPrivileges หากคำสั่งแสดงผลเป็น NoNewPrivileges=yes แสดงว่า drop-in ของคุณถูกส่งไปยัง unit ที่ไม่ได้กำลังทำงานอยู่

ไม่มีข้อมูลภายใน /var/lib/tor/pt_state/ tor ไม่เคยเริ่มการทำงานของ transport ซึ่งหมายความว่า path ใน ServerTransportPlugin ไม่ถูกต้อง ให้เปรียบเทียบกับผลลัพธ์ของ command -v obfs4proxy

ไคลเอนต์หยุดเชื่อมต่อหลังจากมีการเปลี่ยนแปลง การเปลี่ยนแปลงใดๆ ต่อที่อยู่หรือพอร์ต obfs4 จะทำให้ bridge line ทุกบรรทัดที่แจกจ่ายไปแล้วใช้งานไม่ได้ ตรวจสอบว่า IP สาธารณะของเซิร์ฟเวอร์มีการเปลี่ยนแปลงด้วยหรือไม่ ซึ่งมักเกิดขึ้นเมื่อมีการสร้างเซิร์ฟเวอร์ใหม่กับผู้ให้บริการบางราย

tor ไม่เริ่มทำงานเลย ให้รัน sudo -u debian-tor tor --verify-config -f /etc/tor/torrc คำสั่งนี้จะตรวจสอบไฟล์ แสดงบรรทัดที่พบปัญหา และไม่ส่งผลกระทบต่อ service ที่กำลังทำงานอยู่

FAQ

ผู้ให้บริการ VPS จะร้องเรียนเรื่อง Tor bridge ของฉันหรือไม่

Bridge เป็นจุดเชื่อมต่อขาเข้า ดังนั้นทราฟฟิกที่ออกจากเซิร์ฟเวอร์ของคุณจะไปยัง Tor relay อื่นๆ เท่านั้น และไม่ได้ไปยังเว็บไซต์ที่ผู้ใช้เลือก ที่อยู่ IP ของคุณจะไม่ปรากฏใน log ของเว็บไซต์ใดๆ ในฐานะแหล่งที่มาของคำขอ ซึ่งเป็นสาเหตุที่ทำให้ผู้ดูแล exit relay มักได้รับเรื่องร้องเรียน กฎการใช้งานของผู้ให้บริการแต่ละรายมีความแตกต่างกัน และบางรายอาจถือว่าบริการ Tor ทุกประเภทเป็นกรณีพิเศษ ดังนั้นโปรดอ่านนโยบายการใช้งานที่ยอมรับได้ (Acceptable Use Policy) ก่อนเริ่มต้น และระบุที่อยู่อีเมลที่คุณตรวจสอบเป็นประจำไว้ใน ContactInfo

Tor bridge ใช้แบนด์วิดท์มากน้อยเพียงใด

ข้อกำหนดขั้นต่ำที่ประกาศไว้คือ 1 Mbit/s สำหรับขาขึ้นและขาลง เมื่อเทียบกับ 10 Mbit/s สำหรับ guard หรือ middle relay การใช้งานจริงจะเริ่มต้นใกล้ศูนย์ เนื่องจาก bridge ของคุณจะส่งผ่านทราฟฟิกเฉพาะสำหรับผู้ใช้ที่ระบบกระจายสัญญาณส่งมาให้เท่านั้น หากคุณต้องการจำกัดการใช้งานสูงสุด ให้ตั้งค่า RelayBandwidthRate และ RelayBandwidthBurst ใน torrc

ทำไมไม่มีใครเชื่อมต่อกับ bridge ใหม่ของฉัน

Bridge จะใช้เวลาประมาณสามชั่วโมงในการปรากฏบน Relay Search และตามคำแนะนำของ Tor Project การจะมีกลุ่มผู้ใช้ที่สม่ำเสมอต้องใช้เวลาหลายวันหรือหลายสัปดาห์ ให้ตรวจสอบว่ามีการเผยแพร่ descriptor แล้ว ซึ่งดูได้จากบรรทัดการทดสอบตัวเองใน journalctl -u tor@default จากนั้นค้นหา hashed fingerprint ของคุณใน Relay Search และยืนยันว่า BridgeDistribution ไม่ได้ถูกตั้งค่าเป็น none

ฉันควรใช้ obfs4 หรือ WebTunnel

ให้ใช้ obfs4 หากนี่เป็น bridge แรกของคุณ ซึ่งใช้เพียงหนึ่ง VPS, สองพอร์ต, ไม่ต้องใช้โดเมน และไม่ต้องใช้ใบรับรอง ให้ใช้ WebTunnel ในกรณีที่ทราฟฟิกที่มีลักษณะสุ่มถูกบล็อก เนื่องจาก WebTunnel จำเป็นต้องมีโดเมนที่คุณควบคุม, เว็บเซิร์ฟเวอร์จริง, ใบรับรอง TLS ที่ถูกต้อง และ RAM อย่างน้อย 1 GB หากคุณใช้งานทั้งสองอย่าง ให้แยกที่อยู่ IP กัน เพราะหาก IP หนึ่งถูกบล็อก จะทำให้ bridge ทั้งสองตัวใช้งานไม่ได้พร้อมกัน

จะเกิดอะไรขึ้นหากฉันเปลี่ยนพอร์ต obfs4 ในภายหลัง

Bridge line ทุกชุดที่แจกจ่ายไปแล้วจะหยุดทำงานทันที เนื่องจาก bridge line จะผูกที่อยู่, พอร์ต, fingerprint และใบรับรองเข้าด้วยกัน ดังนั้นไคลเอนต์ที่ถือ bridge line เก่าจะพยายามเชื่อมต่อไปยังพอร์ตที่ไม่มีการรับฟังข้อมูลและจะยกเลิกการเชื่อมต่อในที่สุด กรณีนี้จะเกิดขึ้นเช่นเดียวกันหากที่อยู่ IP สาธารณะของเซิร์ฟเวอร์มีการเปลี่ยนแปลง ดังนั้นควรเลือกพอร์ตให้เหมาะสมตั้งแต่ขั้นตอนการติดตั้งและไม่ควรเปลี่ยนแปลงหลังจากนั้น