วิธีการตั้งค่าชื่อโดเมนแบบกำหนดเองสำหรับ Jitsi Meet Docker

วิธีที่สั้นที่สุดในการกำหนดโดเมนเองสำหรับ Jitsi Meet Docker คือการชี้ชื่อโฮสต์ DNS ไปยังโฮสต์ Docker ตั้งค่าPUBLIC_URLเป็น URL HTTPS สุดท้าย กำหนดค่า TLS ที่เชื่อถือได้สำหรับชื่อโฮสต์เดียวกัน และตรวจสอบให้แน่ใจว่าสื่อ WebRTC ยังคงสามารถเข้าถึง Jitsi Videobridge ได้ สำหรับการติดตั้งที่เชื่อมต่อกับอินเทอร์เน็ตโดยตรง การตั้งค่า Docker อย่างเป็นทางการรองรับการสร้างใบรับรองอัตโนมัติในตัวผ่านทางENABLE_LETSENCRYPT, , LETSENCRYPT_DOMAINและLETSENCRYPT_EMAIL

คู่มือนี้ใช้โปรเจกต์ docker-jitsi-meetmeet.example.comมาตรฐานเป็นตัวอย่างที่เป็นรูปธรรม โปรดแทนที่ชื่อโฮสต์ ที่อยู่อีเมล และที่อยู่ IP ในตัวอย่างด้วยค่าของคุณเอง การกำหนดค่าที่อธิบายไว้ในที่นี้ได้รับการตรวจสอบกับคู่มือ Jitsi Docker อย่างเป็นทางการและโปรเจกต์ปัจจุบันณ วันที่ 7 ตุลาคม 2026env.example

สิ่งที่คุณต้องเตรียมก่อนเปลี่ยนโดเมน

การใช้โดเมนแบบกำหนดเองจะได้ผลดีที่สุดเมื่อกำหนดชื่อโฮสต์ก่อนที่จะขอใบรับรอง ตัวอย่างเช่น หากผู้ใช้ควรเปิดhttps://meet.example.comDNS, PUBLIC_URLและใบรับรอง TLS ควรใช้ ทั้งหมด การใช้ชื่อโฮสต์ meet.example.comต่างกันjitsi.example.comในที่หนึ่งและmeet.example.comอีกที่หนึ่งเป็นสาเหตุทั่วไปที่ทำให้เกิดคำเตือนเกี่ยวกับใบรับรองหรือการเปลี่ยนเส้นทางไปยังโฮสต์ที่ไม่ถูกต้อง

• โดเมนที่คุณควบคุมได้
• เซิร์ฟเวอร์ที่ติดตั้ง Docker Engine และ Docker Compose
• ที่อยู่ IP สาธารณะ หรือรีเวิร์สพร็อกซีที่ครอบครองพอร์ต 80 และ 443 อยู่แล้ว
• การเข้าถึงไฟร์วอลล์สำหรับพอร์ตเว็บและทราฟฟิกสื่อของ Jitsi
• ไดเร็กทอรี ที่มีอยู่docker-jitsi-meetและ.envไฟล์ ในนั้น

คู่มืออย่างเป็นทางการของ Jitsi Docker ระบุว่าPUBLIC_URLต้องตั้งค่าให้เป็นโดเมนจริงสำหรับการใช้งานจริง นอกจากนี้ยังระบุพอร์ตภายนอกหลักสำหรับการตั้งค่าโดยตรงแบบมาตรฐาน ได้แก่ 80/TCP, 443/TCP และ 10000/UDP ดูคู่มือการโฮสต์ด้วยตนเองของ Jitsi Docker

ขั้นตอนที่ 1: ชี้ชื่อโฮสต์ที่กำหนดเองไปยังเซิร์ฟเวอร์ Jitsi

สร้างระเบียน A สำหรับชื่อโฮสต์ที่คุณต้องการใช้ ในตัวอย่างนี้meet.example.comชี้ไปยังที่อยู่ IPv4 สาธารณะของเซิร์ฟเวอร์ หากเซิร์ฟเวอร์ของคุณมีการเชื่อมต่อ IPv6 ที่เสถียร คุณอาจเพิ่มระเบียน AAAA ที่ชี้ไปยังที่อยู่ IPv6 สาธารณะของเซิร์ฟเวอร์ได้ด้วย

Type: A
Name: meet
Value: YOUR_PUBLIC_IPV4
TTL: 300

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

ขั้นตอนที่ 2: ตั้งค่า PUBLIC_URL และ HTTPS ในไฟล์ .env

เปิด.envไฟล์ในไดเร็กทอรีที่คุณโคลนหรือแตกไฟล์ออกมาdocker-jitsi-meetสำหรับการใช้งานโดยตรงที่คอนเทนเนอร์เว็บ Jitsi จะรับฟังการเชื่อมต่อจากภายนอกบนพอร์ต 80 และ 443 การตั้งค่าที่สำคัญมีดังนี้:

PUBLIC_URL=https://meet.example.com
HTTP_PORT=80
HTTPS_PORT=443
ENABLE_HTTP_REDIRECT=1
ENABLE_LETSENCRYPT=1
LETSENCRYPT_DOMAIN=meet.example.com
LETSENCRYPT_EMAIL=admin@example.com
LETSENCRYPT_ACME_SERVER=letsencrypt

PUBLIC_URLไม่ใช่แค่เรื่องความสวยงามเท่านั้น Jitsi ใช้มันในการสร้างการกำหนดค่าที่มีประสิทธิภาพ ดังนั้นการปล่อยไว้ที่ localhost หรือชื่อโฮสต์เก่าอาจทำให้ลิงก์เสียและพฤติกรรมไม่สอดคล้องกัน ตัวอย่างโครงการปัจจุบันยังระบุด้วยว่า หากคุณจงใจใช้พอร์ต HTTPS ที่ไม่ใช่มาตรฐาน พอร์ตนั้นควรอยู่ในPUBLIC_URL.

ตัวอย่างอย่างเป็นทางการในปัจจุบันระบุ ZeroSSL เป็นเซิร์ฟเวอร์ ACME เริ่มต้น และอนุญาตให้LETSENCRYPT_ACME_SERVER="letsencrypt"ใช้ Let's Encrypt ได้เมื่อคุณต้องการ หากการติดตั้งที่มีอยู่ของคุณได้รับใบรับรองที่เชื่อถือได้สำเร็จแล้ว ให้คงการตั้งค่า ACME ที่ตรงกับสภาพแวดล้อมการทำงานของคุณไว้ แทนที่จะเปลี่ยนผู้ให้บริการโดยไม่มีเหตุผล

ขั้นตอนที่ 3: เปิดพอร์ตไฟร์วอลล์ที่จำเป็น

สำหรับการใช้งาน Docker ที่เชื่อมต่อกับอินเทอร์เน็ตโดยตรงตามที่อธิบายไว้ข้างต้น ให้เปิดใช้งานพอร์ต 80/TCP, 443/TCP และ 10000/UDP และเปิดพอร์ตการจัดการ SSH ไว้ด้วย ตัวอย่างขั้นต่ำบนโฮสต์ Ubuntu ที่ใช้ UFW มีดังนี้:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 10000/udp
sudo ufw status verbose

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

หากโฮสต์ของคุณอยู่หลัง NAT โปรดตรวจสอบเพิ่มเติมด้วยJVB_ADVERTISE_IPSคู่มืออย่างเป็นทางการอธิบายว่าตัวแปรนี้ควบคุมที่อยู่ซึ่ง Jitsi Videobridge ประกาศสำหรับสื่อ และจำเป็นในระบบ LAN หรือ NAT หลายๆ ระบบ ตัวอย่างทั่วไปในอินเทอร์เน็ตสาธารณะคือ:

JVB_ADVERTISE_IPS=YOUR_PUBLIC_IPV4

ขั้นตอนที่ 4: รีสตาร์ท Docker stack ด้วยโดเมนใหม่

บันทึก.envจากนั้นสร้างคอนเทนเนอร์ขึ้นใหม่เพื่อให้การเปลี่ยนแปลงสภาพแวดล้อมมีผล:

docker compose down
docker compose up -d
docker compose ps

การใช้คำ สั่ง `recreate` แบบง่ายๆrestartอาจไม่ใช่ทางเลือกที่ดีที่สุดหลังจากเปลี่ยนตัวแปรสภาพแวดล้อม เพราะคำจำกัดความของคอนเทนเนอร์ที่มีอยู่เดิมอาจยังคงมีสภาพแวดล้อมเดิมอยู่ การสร้างสแต็กใหม่จะทำให้PUBLIC_URLค่าพอร์ตและค่าใบรับรองใหม่มีความชัดเจนมากขึ้น

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

ขั้นตอนที่ 5: ยืนยัน DNS และ HTTPS จากภายนอกเซิร์ฟเวอร์

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

dig +short meet.example.com

จากนั้นทดสอบเอนด์พอยต์ HTTPS:

curl -I https://meet.example.com

การตอบสนองที่สำเร็จแสดงให้เห็นว่า DNS, TCP 443 และบริการเว็บทำงานร่วมกันได้ แต่ยังไม่ได้พิสูจน์ว่าระบบสื่อหลายฝ่ายทำงานได้ ดังนั้นนี่จึงเป็นการตรวจสอบขั้นกลาง ไม่ใช่จุดสิ้นสุดของกระบวนการ

หากได้digที่อยู่เก่ากลับมา ให้รอจนกว่า DNS จะหมดอายุ TTL หรือแก้ไขระเบียน หาก DNS ถูกต้องแต่curlหมดเวลา ให้ตรวจสอบกลุ่มความปลอดภัยบนคลาวด์ ไฟร์วอลล์ของโฮสต์ กฎเราเตอร์/NAT และตรวจสอบว่ามีบริการอื่นใช้งานพอร์ต 443 อยู่แล้วหรือไม่

ขั้นตอนที่ 6: ตรวจสอบการออกใบรับรองและบันทึกเว็บ

หากเบราว์เซอร์ยังคงแสดงคำเตือนเกี่ยวกับใบรับรอง ให้ตรวจสอบบันทึกของเว็บคอนเทนเนอร์แทนที่จะลบการกำหนดค่าและขอใบรับรองใหม่ซ้ำๆ:

docker compose logs --tail=200 web

ตรวจสอบหาข้อผิดพลาดในการตรวจสอบความถูกต้องของ ACME ความล้มเหลวในการผูกพอร์ต หรือความไม่ตรงกันของชื่อโฮสต์ คู่มือ Jitsi เตือนเกี่ยวกับข้อจำกัดอัตราการใช้งานของหน่วยงานออกใบรับรอง และแนะนำให้เก็บรักษาพื้นที่จัดเก็บการกำหนดค่าที่มีใบรับรองที่ออกให้ไว้ ในระหว่างการทดลองตั้งค่าซ้ำๆ การใช้สภาพแวดล้อมทดสอบ (staging) อาจมีประโยชน์ แต่หลังจากเปลี่ยนไปใช้สภาพแวดล้อมทดสอบแล้ว คู่มือระบุว่าอาจจำเป็นต้องล้างข้อมูลใบรับรองเก่าจากสภาพแวดล้อมทดสอบออกจากพื้นที่จัดเก็บข้อมูลบนเว็บก่อนที่จะขอใบรับรองสำหรับการใช้งานจริง

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

ขั้นตอนที่ 7: เปิดโดเมนที่กำหนดเองในเบราว์เซอร์

เข้าชมhttps://meet.example.comเว็บไซต์ผ่านเบราว์เซอร์ที่ทันสมัย ​​คุณควรจะเห็นหน้า Landing Page ของ Jitsi ภายใต้ชื่อโฮสต์ที่คุณเลือก พร้อมตัวบ่งชี้ TLS ที่ถูกต้อง สร้างห้องทดสอบโดยใช้ชื่อชั่วคราว

ควรใช้ HTTPS สำหรับการประชุมจริง คู่มืออย่างเป็นทางการของ Docker เตือนไว้อย่างชัดเจนว่า การเข้าถึงโดยตรงผ่าน HTTP อาจทำให้ API WebRTC ของเบราว์เซอร์ เช่น การเข้าถึงไมโครโฟนและกล้อง ล้มเหลว ดังนั้น HTTPS จึงเป็นส่วนหนึ่งของการกำหนดค่าการทำงาน ไม่ใช่เพียงแค่มาตรการรักษาความปลอดภัยเท่านั้น

ขั้นตอนที่ 8: ทดสอบการโทรจริง ไม่ใช่แค่หน้าแรก

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

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

เมื่อใดที่คุณควรใช้ Reverse Proxy แทน

การกำหนดค่าโดยตรงข้างต้นเหมาะสมเมื่อเว็บคอนเทนเนอร์ Jitsi สามารถเป็นเจ้าของพอร์ตสาธารณะ 80 และ 443 ได้ หากเซิร์ฟเวอร์เดียวกันนั้นใช้งาน Nginx, Apache, Caddy, Traefik หรือพร็อกซีอื่น ๆ บนพอร์ตเหล่านั้นอยู่แล้ว อย่าพยายามผูก Jitsi กับพอร์ตเหล่านั้นพร้อมกัน

สำหรับ Reverse Proxy ที่ทำงานบนโฮสต์เดียวกัน คู่มือ Docker อย่างเป็นทางการของ Jitsi แนะนำให้ปิดใช้งาน HTTPS ภายในคอนเทนเนอร์ Jitsi หลีกเลี่ยงการเปิดเผยพอร์ตเว็บภายในสู่สาธารณะ และส่งต่อคำขอไปยัง HTTP ingress ของคอนเทนเนอร์ นอกจากนี้ Proxy ต้องรองรับการส่งต่อ WebSocket ด้วย/xmpp-websocketสภาพแวดล้อมฝั่ง Jitsi ทั่วไปจะเป็นดังนี้:

DISABLE_HTTPS=1
ENABLE_HTTP_REDIRECT=0
ENABLE_LETSENCRYPT=0
PUBLIC_URL=https://meet.example.com

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

การแก้ไขปัญหาความล้มเหลวของโดเมนที่กำหนดเอง

โดเมนเก่าจะยังคงปรากฏอยู่แม้หลังจากแก้ไขไฟล์ .env แล้ว

สร้างคอนเทนเนอร์ขึ้นใหม่โดยใช้คำสั่ง `recreate containers` docker compose downตามด้วยdocker compose up -d`.` และตรวจสอบให้แน่ใจว่าคุณได้แก้ไข.envไฟล์ที่ใช้โดยโปรเจ็กต์ Compose ที่คุณกำลังเริ่มต้นใช้งานจริงแล้ว

การตรวจสอบความถูกต้องของใบรับรอง HTTPS ล้มเหลว

ตรวจสอบให้แน่ใจว่าระเบียน DNS A/AAAA ชี้ไปยังเซิร์ฟเวอร์ที่รับคำท้า และพอร์ตสาธารณะ 80 สามารถเข้าถึงได้เมื่อใช้กระบวนการขอใบรับรองโดยตรงแบบในตัว ตรวจสอบdocker compose logs webข้อผิดพลาด ACME ที่แน่นอนก่อนทำการร้องขออีกครั้ง

หน้าเว็บโหลดเสร็จแล้ว แต่ผู้เข้าร่วมไม่มีเสียงหรือภาพ

ตรวจสอบ UDP 10000 และสำหรับการใช้งาน NAT ให้ตั้งค่าให้ถูกต้องJVB_ADVERTISE_IPSโปรดจำไว้ว่าพร็อกซีแบบย้อนกลับทำหน้าที่จัดการทราฟฟิกเว็บ ไม่ได้มาแทนที่เส้นทางสื่อของ Videobridge

เบราว์เซอร์ใช้งานได้ แต่แอปบนมือถือปฏิเสธการเชื่อมต่อกับเซิร์ฟเวอร์

ตรวจสอบห่วงโซ่ใบรับรอง คู่มือ Jitsi Docker ระบุว่าแอปพลิเคชันบนมือถือไม่สามารถใช้งานได้กับใบรับรองแบบลงนามเองตามค่าเริ่มต้น ให้ใช้ใบรับรองที่ได้รับการยอมรับจากสาธารณะ หรือออกแบบโครงสร้างพื้นฐานที่แอปได้รับห่วงโซ่ใบรับรองที่เชื่อถือได้

รายการตรวจสอบการยืนยันขั้นสุดท้าย

• meet.example.comส่งสัญญาณไปยังที่อยู่สาธารณะที่ต้องการ
• PUBLIC_URL=https://meet.example.comตรงกับ URL ของเบราว์เซอร์อย่างแม่นยำ
• ใบรับรอง TLS เชื่อถือได้และครอบคลุมถึงmeet.example.com...
• สามารถเข้าถึงพอร์ต 80/TCP และ 443/TCP เพื่อการตั้งค่าโดยตรงได้
• แพ็กเก็ต UDP 10000 ส่งมาถึงโฮสต์ Jitsi Videobridge
• JVB_ADVERTISE_IPSถูกต้องเมื่อเซิร์ฟเวอร์อยู่หลัง NAT หรือต้องการที่อยู่ IP ที่ระบุอย่างชัดเจน
• docker compose psแสดงคอนเทนเนอร์ที่จำเป็นที่กำลังทำงานอยู่
• การทดสอบที่มีผู้เข้าร่วมสองคนสามารถส่งสัญญาณเสียงและวิดีโอได้สำเร็จ

เมื่อการตรวจสอบเหล่านั้นผ่านแล้ว โดเมนที่กำหนดเองจะไม่เพียงชี้ไปยัง Jitsi เท่านั้น แต่ยังได้รับการกำหนดค่าสำหรับส่วนที่สำคัญจริง ๆ ในการประชุมด้วย ได้แก่ HTTPS การส่งสัญญาณ และการรับส่งสื่อ

เอกสารอ้างอิงอย่างเป็นทางการ

• คู่มือการใช้งาน Jitsi Meet แบบ Self-Hosting — Docker
• ตัวอย่างสภาพแวดล้อม docker-jitsi-meet
• แหล่งเก็บโค้ดอย่างเป็นทางการของ docker-jitsi-meet