วิธีแก้ไขข้อผิดพลาด “ไม่สามารถเชื่อมต่อกับบริดจ์ได้” ใน Jitsi Meet

คุณเปิดห้อง Jitsi Meet หน้าเว็บโหลดตามปกติ และการส่งสัญญาณอาจดูเหมือนใช้งานได้ แต่การประชุมไม่สามารถสร้างสื่อได้ แทนที่จะเป็นเช่นนั้น Jitsi จะรายงานว่า“ไม่สามารถเชื่อมต่อกับบริดจ์ได้”หรือตัดการเชื่อมต่อซ้ำๆ ขณะเข้าร่วม ในการติดตั้งแบบโฮสต์เอง ข้อความดังกล่าวโดยทั่วไปบ่งชี้ถึงปัญหาที่เกิดขึ้นระหว่างเบราว์เซอร์กับJitsi Videobridge (JVB)หรือระหว่าง Jicofo กับบริดจ์เอง

วิธีแก้ไขปัญหาที่เร็วที่สุดคือการเริ่มจากฝั่งเซิร์ฟเวอร์: ตรวจสอบว่า JVB ทำงานและลงทะเบียนแล้ว ตรวจสอบว่าพอร์ตมีเดียสามารถเข้าถึงได้ ตรวจสอบการจัดการ NAT/ที่อยู่สาธารณะ จากนั้นจึงค่อยตรวจสอบข้อจำกัดของเครือข่ายฝั่งไคลเอ็นต์ คู่มือการโฮสต์ด้วยตนเองอย่างเป็นทางการของ Jitsi ระบุว่าพอร์ต UDP 10000 เป็นเส้นทางมีเดียเริ่มต้น ในขณะที่ Jicofo มีหน้าที่เลือก Videobridge สำหรับการประชุมแต่ละครั้ง

ข้อผิดพลาดนั้นโดยทั่วไปหมายความว่าอย่างไร

Jitsi Meet ประกอบด้วยหลายส่วน ส่วนติดต่อผู้ใช้บนเว็บและ Prosody ทำหน้าที่ส่งสัญญาณ Jicofo ทำหน้าที่ประสานงานการประชุม และ Jitsi Videobridge ทำหน้าที่ส่งต่อสตรีมเสียงและวิดีโอ หากเบราว์เซอร์สามารถเข้าถึงหน้าเว็บได้ แต่ไม่สามารถสร้างการเชื่อมต่อสื่อกับ JVB ได้ หรือหาก Jicofo ไม่มีบริดจ์ที่ใช้งานได้ การประชุมอาจล้มเหลวในขั้นตอนการเชื่อมต่อบริดจ์

สำหรับระบบ Debian/Ubuntu ในปัจจุบัน เอกสารของ Jitsi ระบุข้อกำหนดด้านเครือข่ายดังนี้: TCP 80 สำหรับการตรวจสอบและต่ออายุใบรับรอง, TCP 443 สำหรับการเข้าถึงเว็บ, UDP 10000 สำหรับเสียง/วิดีโอทั่วไป, UDP 3478 สำหรับการสอบถาม STUN (ไม่บังคับ) และ TCP 5349 สำหรับสื่อสำรองแบบ coturn เมื่อ UDP ถูกบล็อก ดูคู่มือการติดตั้ง Jitsi บน Debian/Ubuntu อย่างเป็นทางการการกำหนดค่าอ้างอิงปัจจุบันของ JVB ยังแสดงพอร์ต UDP 10000 เป็นพอร์ต ICE/UDP เริ่มต้นในเอกสารการกำหนดค่าอ้างอิงของ Jitsi Videobridgeด้วย

1. ตรวจสอบว่า Jitsi Videobridge กำลังทำงานอยู่

เริ่มจากส่วนประกอบที่ระบุในข้อผิดพลาด สำหรับการติดตั้งแบบแพ็กเกจมาตรฐาน ให้รันคำสั่ง:

sudo systemctl status jitsi-videobridge2

คุณต้องการดูว่าเกิดอะไรขึ้นactive (running)หากอุปกรณ์ทำงานผิดพลาด การรีสตาร์ทอาจช่วยให้ใช้งานได้ชั่วคราว แต่ห้ามหยุดเพียงแค่นั้น ให้ตรวจสอบบันทึกเพื่อหาสาเหตุที่อุปกรณ์หยุดทำงาน:

sudo systemctl restart jitsi-videobridge2
sudo journalctl -u jitsi-videobridge2 -n 200 --no-pager

ตรวจสอบหาข้อผิดพลาดในการเชื่อมต่อ (bind failures), ข้อผิดพลาดในการตรวจสอบสิทธิ์ (authentication errors), การเชื่อมต่อ XMPP ล้มเหลว (XMPP connection failures), ปัญหา ICE ซ้ำๆ หรือข้อความที่ระบุว่าไม่มีที่อยู่ IP ที่ถูกต้อง อย่าคิดว่าสถานะ systemd ที่แสดงขึ้นมาจะพิสูจน์ได้ว่า JVB สามารถใช้งานได้เสมอไป เพราะกระบวนการ Java อาจกำลังทำงานอยู่ขณะที่การเชื่อมต่อเครือข่ายสื่อหรือการลงทะเบียน XMPP มีปัญหา

2. ตรวจสอบว่าพอร์ต UDP 10000 เปิดใช้งานและได้รับอนุญาตให้ผ่านไฟร์วอลล์ของโฮสต์แล้ว

พอร์ตมีเดีย JVB เริ่มต้นของ Jitsi คือ UDP 10000 ก่อนอื่น โปรดตรวจสอบว่าเซิร์ฟเวอร์กำลังรับฟังอยู่หรือไม่:

sudo ss -lunp | grep ':10000'

หากไม่มีสิ่งใดกำลังรับฟังอยู่ ให้ตรวจสอบ/etc/jitsi/videobridge/jvb.confบันทึก JVB ก่อนที่จะเปลี่ยนแปลงกฎไฟร์วอลล์ หากพอร์ตกำลังรับฟังอยู่ ให้ตรวจสอบไฟร์วอลล์ของโฮสต์:

sudo ufw status verbose

บนเซิร์ฟเวอร์ Ubuntu ที่ใช้ UFW คู่มือของ Jitsi เองได้ระบุไว้ดังนี้:

sudo ufw allow 10000/udp
sudo ufw status verbose

หากคุณใช้ firewalld, nftables, iptables หรือไฟร์วอลล์บนคลาวด์แทน UFW ให้เพิ่มกฎ UDP ขาเข้าที่เทียบเท่ากันลงในที่เหล่านั้น ข้อผิดพลาดที่พบบ่อยคือการเปิดพอร์ต UDP 10000 ใน Ubuntu แต่ปล่อยให้มันถูกบล็อกโดยกลุ่มความปลอดภัยของ AWS, กลุ่มความปลอดภัยเครือข่าย Azure, ไฟร์วอลล์ Google Cloud VPC, ไฟร์วอลล์ของผู้ให้บริการ VPS หรือไฟร์วอลล์ฮาร์ดแวร์ต้นทาง

3. ตรวจสอบการตั้งค่าการส่งต่อพอร์ตของเราเตอร์เมื่อเซิร์ฟเวอร์อยู่หลัง NAT

หาก Jitsi ทำงานบนที่อยู่ IP ส่วนตัว เช่น192.168.x.xการเปิด UFW อย่างเดียวไม่เพียงพอ เราเตอร์ขอบเครือข่ายของคุณต้องส่งต่อพอร์ตสื่อ UDP ภายนอกไปยังเครื่องที่ใช้งาน JVB ในการติดตั้งแบบเซิร์ฟเวอร์เดียวอย่างง่าย โดยทั่วไปแล้วหมายถึงการส่งต่อ UDP 10000 ไปยัง UDP 10000 บนเซิร์ฟเวอร์ Jitsi

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

4. แก้ไขการแมปที่อยู่สาธารณะ/ส่วนตัว

NAT อาจทำให้เกิดความล้มเหลวที่ซ่อนเร้นกว่านั้นได้: JVB อาจประกาศ IP ส่วนตัวให้กับไคลเอ็นต์อินเทอร์เน็ต แม้ว่าเราเตอร์จะส่งต่อพอร์ตที่ถูกต้องแล้วก็ตาม เอกสารเริ่มต้นใช้งานฉบับย่อของ Jitsi ในปัจจุบันแสดงการแมปแบบคงที่/etc/jitsi/videobridge/jvb.confสำหรับระบบที่ต้องการการแปลง IP จาก IP ภายในเป็น IP สาธารณะอย่างชัดเจน:

ice4j {
  harvest {
    mapping {
      static-mappings = [
        {
          local-address = "<Local.IP.Address>"
          public-address = "<Public.IP.Address>"
        }
      ]
    }
  }
}

แทนที่ตัวยึดตำแหน่งด้วยที่อยู่ส่วนตัวจริงของโฮสต์ JVB และที่อยู่สาธารณะที่ไคลเอ็นต์ระยะไกลสามารถเข้าถึงได้ จากนั้นรีสตาร์ท JVB:

sudo systemctl restart jitsi-videobridge2

ใช้การตั้งค่านี้เฉพาะเมื่อตรงกับโครงสร้างเครือข่ายของคุณเท่านั้น เซิร์ฟเวอร์ที่มีการกำหนดแอดเดรสสาธารณะโดยตรง การใช้งาน Docker การ์ดเครือข่ายหลายตัว IPv6 หรือ NAT ที่ซับซ้อนกว่า อาจต้องการการตั้งค่าที่แตกต่างกัน ตัวอย่างที่ถูกต้องอยู่ในส่วน NAT เริ่มต้นใช้งานอย่างรวดเร็วของ Jitsi

5. สำหรับ Docker ให้ตรวจสอบว่าพอร์ต JVB UDP ถูกเปิดใช้งานจริงหรือไม่

ใน Docker การตั้งค่ากฎไฟร์วอลล์ที่ถูกต้องบนโฮสต์จะไม่ช่วยอะไรหากคอนเทนเนอร์ JVB ไม่เปิดพอร์ตมีเดีย เอกสารของ Jitsi เกี่ยวกับ Docker ระบุค่าJVB_PORTเริ่มต้นไว้ที่ 10000 และแนะนำให้ผู้ดูแลระบบเปิดพอร์ต UDP 10000 บนโฮสต์ โปรดตรวจสอบการใช้งาน Docker ของคุณ:

docker compose ps
docker compose logs --tail=200 jvb

จากนั้นตรวจสอบไฟล์ Compose และไฟล์สภาพแวดล้อมของคุณ และยืนยันว่าบริการ JVB เปิดเผยพอร์ต UDP ที่ต้องการ หากคุณเปลี่ยนแปลงJVB_PORTการแมปโฮสต์ กฎไฟร์วอลล์ และการส่งต่อ NAT ทั้งหมดต้องสอดคล้องกัน โปรดดูคู่มือการโฮสต์ Docker ด้วยตนเองอย่างเป็นทางการของ Jitsiแทนการคัดลอกโค้ด Compose เก่าจากบทช่วยสอนของบุคคลที่สาม

6. ตรวจสอบว่า Jicofo สามารถมองเห็น Videobridge ได้หรือไม่

พอร์ต UDP ที่สามารถเข้าถึงได้อย่างสมบูรณ์แบบนั้นไม่เพียงพอ หาก JVB ไม่ลงทะเบียนกับระนาบควบคุม XMPP Jicofo จะเลือก Videobridge สำหรับการประชุม และคู่มือการปรับใช้แบบปรับขนาดได้ของ Jitsi แนะนำให้ตรวจสอบบันทึกของทั้ง Prosody และ Jicofo หลังจากรีสตาร์ทบริการ เพื่อยืนยันว่าบริดจ์เชื่อมต่อและถูกเลือกใช้งานแล้ว

sudo journalctl -u jicofo -n 200 --no-pager
sudo journalctl -u prosody -n 200 --no-pager
sudo journalctl -u jitsi-videobridge2 -n 200 --no-pager

หากคุณปรับแต่งโดเมน XMPP หรือใช้งานหลายโหนด โปรดตรวจสอบให้แน่ใจว่า Jicofo และ JVB ใช้ MUC “brewery” เดียวกันเอกสารอย่างเป็นทางการของ Jitsi Videobridge MUCระบุว่า Jicofo jicofo.bridge.brewery-jidต้องชี้ไปยัง MUC เดียวกันกับที่ใช้โดยอินสแตนซ์ Videobridge

สิ่งนี้สำคัญอย่างยิ่งหลังจากมีการเปลี่ยนแปลงชื่อโฮสต์ การย้ายระบบ การติดตั้งแบบแยกโฮสต์ หรือการแก้ไขการกำหนดค่าด้วยตนเอง สำหรับการติดตั้งแพ็กเกจมาตรฐานที่สร้างด้วยตัวติดตั้งอย่างเป็นทางการ ควรหลีกเลี่ยงการเขียนทับการกำหนดค่า XMPP เว้นแต่ว่าบันทึกของคุณจะระบุถึงปัญหาการลงทะเบียนหรือการตรวจสอบสิทธิ์จริงๆ

7. หลีกเลี่ยงการใช้เครือข่ายไคลเอ็นต์ที่จำกัด, VPN หรือพร็อกซี

หากเซิร์ฟเวอร์ใช้งานได้สำหรับผู้ใช้บางรายแต่ไม่ได้ผลสำหรับรายอื่น ให้ทดสอบจากเครือข่ายอื่นก่อนที่จะเปลี่ยนแปลงการตั้งค่าเซิร์ฟเวอร์ เครือข่ายองค์กร Wi-Fi สำหรับแขก VPN และพร็อกซีที่เข้มงวดอาจบล็อก UDP การตัดการเชื่อมต่อ VPN หรือพร็อกซีชั่วคราวเป็นการทดสอบวินิจฉัยที่มีประโยชน์ จากนั้นเชื่อมต่อใหม่หากองค์กรของคุณกำหนดไว้

คู่มือ Debian/Ubuntu ของ Jitsi ระบุว่า TCP 5349 เป็นเส้นทางสำรองของ coturn สำหรับเสียง/วิดีโอเมื่อ UDP ถูกบล็อก หากคุณต้องการให้ผู้ใช้ในเครือข่ายที่มีข้อจำกัดสามารถเชื่อมต่อได้อย่างน่าเชื่อถือ โปรดตรวจสอบการตั้งค่า TURN/coturn ของคุณ แทนที่จะคิดว่าการเปิด TCP 443 สำหรับเว็บไซต์จะให้การเชื่อมต่อสำรองสำหรับสื่อโดยอัตโนมัติ

8. ลองใหม่อีกครั้งด้วยเบราว์เซอร์ที่สะอาดหมดจดหลังจากที่การตรวจสอบเซิร์ฟเวอร์ผ่านแล้วเท่านั้น

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

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

วิธีตรวจสอบว่าการแก้ไขได้ผลจริงหรือไม่

อย่าคิดว่าปัญหาได้รับการแก้ไขแล้วเพียงเพราะข้อความแสดงข้อผิดพลาดหายไป ตรวจสอบเส้นทางไฟล์มีเดียทั้งหมดอีกครั้ง

• สร้างห้องใหม่และเข้าร่วมจากอุปกรณ์สองเครื่อง
• ถ้าเป็นไปได้ ให้เชื่อมต่ออุปกรณ์เข้ากับเครือข่ายที่แตกต่างกัน เช่น เครื่องหนึ่งใช้บรอดแบนด์บ้าน และอีกเครื่องใช้ข้อมูลมือถือ
• ตรวจสอบให้แน่ใจว่าทั้งเสียงและภาพส่งผ่านได้ทั้งสองทิศทางเป็นเวลาหลายนาที
• ขณะเข้าร่วมการประชุม โปรดตรวจสอบบันทึก JVB และ Jicofo และยืนยันว่าการประชุมได้รับการกำหนดให้กับบริดจ์ที่ไม่มีข้อผิดพลาด ICE หรือความล้มเหลวของสถานะบริดจ์ซ้ำๆ
• เรียกใช้sudo ss -lunp | grep ':10000'การตรวจสอบสถานะไฟร์วอลล์อีกครั้งหลังจากรีบูตหรือเปลี่ยนแปลงการตั้งค่าไฟร์วอลล์ใดๆ

สำหรับการติดตั้งแบบหลายบริดจ์ ให้ทดสอบการประชุมมากกว่าหนึ่งครั้งคู่มือการตั้งค่าแบบปรับขนาดได้ ของ Jitsi อธิบายว่า Jicofo จะเลือก Videobridge สำหรับการประชุมใหม่ ดังนั้นบริดจ์ที่ไม่ทำงานตัวใดตัวหนึ่งอาจทำให้เกิดความล้มเหลวเป็นระยะๆ แม้ว่าบริดจ์อื่นจะทำงานได้ก็ตาม

ตารางการวินิจฉัยอย่างรวดเร็ว

สรุปแล้ว

สำหรับเซิร์ฟเวอร์ Jitsi Meet ที่ติดตั้งเอง หากพบข้อความ “Failed to connect to bridge” ควรตรวจสอบปัญหาที่เส้นทางสื่อหรือการลงทะเบียนบริดจ์ก่อน ตรวจสอบให้แน่ใจว่า Jitsi Videobridge ทำงานได้อย่างปกติ พอร์ต UDP 10000 เปิดใช้งานและสามารถเข้าถึงได้ผ่านไฟร์วอลล์/NAT ทุกชั้น JVB ประกาศที่อยู่สาธารณะที่ใช้งานได้เมื่อมีการใช้งาน NAT และ Jicofo มองเห็นบริดจ์ หลังจากตรวจสอบสิ่งเหล่านี้แล้ว จึงค่อยเสียเวลาไปกับการตรวจสอบแคชของเบราว์เซอร์หรือการตั้งค่าไคลเอ็นต์แต่ละราย

วิธีแก้ไขที่ถูกต้องนั้นขึ้นอยู่กับโครงสร้างเครือข่ายของคุณ ดังนั้นควรหลีกเลี่ยงการใช้คีย์การกำหนดค่า Jitsi เก่าๆ เพียงเพราะว่ามันปรากฏอยู่ในกระทู้เก่าๆ คำสั่งและการตั้งค่าข้างต้นนั้นสอดคล้องกับคู่มือ Jitsi อย่างเป็นทางการฉบับปัจจุบันและแหล่งข้อมูลการกำหนดค่า Jitsi Videobridge ฉบับปัจจุบันที่ตรวจสอบแล้วในเดือนตุลาคม 2026