如何為 Jitsi Meet Docker 配置自訂域名

為 Jitsi Meet Docker 設定自訂網域的最短路徑是：將 DNS 主機名稱指向 Docker 主機，並將其設定為最終的 HTTPS URL，為該主機名稱配置受信任的 TLS，並確保 WebRTC 媒體仍可存取 Jitsi Videobridge。對於直接面向互聯網的安裝，官方 Docker 設定支援透過 `<container_name>` 、`<container_name>` 和PUBLIC_URL`<container_name>` 實現內建憑證自動化。ENABLE_LETSENCRYPTLETSENCRYPT_DOMAINLETSENCRYPT_EMAIL

本指南以標準docker-jitsi-meet 專案meet.example.com為例進行說明。請將範例中的主機名稱、電子郵件位址和僅供文件使用的 IP 位址替換為您自己的值。此處所述的配置已於 2026 年 10 月 7 日根據官方 Jitsi Docker 手冊和當前專案進行驗證。env.example

更改網域前需要準備什麼

自訂網域在申請證書之前確定主機名稱效果最佳。例如，如果使用者需要開啟某個網址https://meet.example.com，DNS、DNS 伺服器PUBLIC_URL和 TLS 憑證都應該使用同一個主機名稱meet.example.com。jitsi.example.com在不同的地方混用主機名稱meet.example.com是導致憑證警告或重定向到錯誤主機的常見原因。

• 您控制的網域名稱。
• 一台安裝了 Docker Engine 和 Docker Compose 的伺服器。
• 一個公用 IP 位址，或一個已經擁有 80 和 443 連接埠的反向代理。
• 防火牆對 Web 連接埠和 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圖示中的設定直接複製到實際部署環境中；該位址僅用於文件說明。如果您使用具有代理/CDN 模式的 DNS 提供者，請先使用普通的 DNS 解析，除非您已確認該代理程式支援您打算使用的 Jitsi 流量模式。

步驟 2：在 .env 檔案中設定 PUBLIC_URL 和 HTTPS 值

開啟.env您克隆或解壓縮到的目錄中的檔案docker-jitsi-meet。對於直接部署（Jitsi Web 容器將監聽 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 管理連接埠開放。在執行 UFW 的 Ubuntu 主機上，以下是一個最小範例：

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

Web 連接埠用於網站和憑證驗證。 UDP 10000 是 Jitsi Videobridge 的預設媒體連接埠。如果媒體連接埠被阻止，即使頁面加載正常，會議仍然可能失敗或丟失音頻/視頻，因此僅檢查 HTTPS 是不夠的。

如果您的主機位於 NAT 之後，也請查看相關設定JVB_ADVERTISE_IPS。官方手冊解釋說，此變數控制 Jitsi Videobridge 為媒體通告的位址，在許多 LAN 或 NAT 部署中都是必要的。一個典型的公共互聯網範例是：

JVB_ADVERTISE_IPS=YOUR_PUBLIC_IPV4

步驟 4：使用新網域重新啟動 Docker 堆疊

儲存.env後，重新建立容器，以便套用環境變更：

docker compose down
docker compose up -d
docker compose ps

更改環境變數後，簡單地重新restart建立容器並非最佳選擇，因為現有的容器定義可能仍然包含先前的環境變數。重新建立容器堆疊可以PUBLIC_URL明確地套用新的環境變數、連接埠值和憑證設定。

如果您是從專案全新副本開始，請先按照官方快速入門步驟操作，包括產生所需密碼和建立設定目錄。最新的 Jitsi 容器版本以非特權使用者身分執行服務，並且需要可寫入儲存和臨時目錄，因此全新安裝應遵循當前手冊中的目錄命令，而不是舊的第三方教學。

步驟 5：從伺服器外部確認 DNS 和 HTTPS

DNS 解析完成後，檢查主機名稱是否解析到預期的公有網路位址：

dig +short meet.example.com

然後測試HTTPS端點：

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

成功回應證明 DNS、TCP 443 連接埠和 Web 服務協同工作。但這並不能證明多方媒體通訊正常，因此這只是一個中間檢查步驟，而非最終結果。

如果dig傳回的是舊位址，請等待 DNS TTL 到期或修正記錄。如果 DNS 正確但curl逾時，請檢查雲端安全群組、主機防火牆、路由器/NAT 規則，以及是否有其他服務佔用 443 連接埠。

步驟 6：檢查證書頒發狀況和 Web 日誌

如果瀏覽器仍然顯示憑證警告，請檢查 Web 容器日誌，而不是重複刪除設定並要求另一個憑證：

docker compose logs --tail=200 web

檢查是否有 ACME 驗證錯誤、連接埠綁定失敗或主機名稱不符。 Jitsi 手冊警告注意憑證授權單位的速率限制，並建議保留包含已核發憑證的設定儲存。在重複設定實驗期間，暫存環境可能很有用，但手冊指出，在停止使用暫存環境後，可能需要先從 Web 儲存中清除舊的暫存憑證資料，然後再申請生產憑證。

如果您已經擁有來自其他來源的受信任證書，Jitsi 也支援將現有的完整證書鍊和私鑰掛載到 Web 服務中，而無需啟用內建的 ACME 流程。請參考官方現有證書部分的證書掛載範例。

步驟 7：在瀏覽器中開啟自訂域名

請使用現代瀏覽器存取https://meet.example.com。您應該會在您選擇的主機名稱下看到 Jitsi 登入頁面，並帶有有效的 TLS 指示器。建立一個臨時名稱的測試房間。

實際會議請使用 HTTPS。 Docker 官方指南明確警告，直接使用 HTTP 存取可能會導致瀏覽器 WebRTC API（例如麥克風和相機存取）失敗。因此，HTTPS 不僅是安全措施，更是功能配置的一部分。

步驟 8：測試真實通話，而不僅僅是主頁。

如果可能，請使用兩台不同的設備或網路加入同一房間。確認每位參與者都能發送和接收音訊和視訊。雙瀏覽器測試非常重要，因為即使安裝成功，網站也能正常運行，但 Videobridge 位址或 UDP 路徑可能仍然錯誤。

對於位於 NAT 後面的部署，一個常見的症狀是：首次連線看似正常，但隨著更多參與者加入，媒體傳輸會失敗。在這種情況下，請重新檢查JVB_ADVERTISE_IPS公共 NAT 對映和 UDP 10000 連接埠。 Jitsi 手冊明確指出，即使 HTTP 流量由反向代理處理，Videobridge 媒體位址仍然有效。

何時應該使用反向代理

當 Jitsi Web 容器可以擁有公用連接埠 80 和 443 時，上述直接配置是適當的。如果同一台伺服器已經在這些連接埠上執行 Nginx、Apache、Caddy、Traefik 或其他代理，請不要同時嘗試將 Jitsi 綁定到它們。

對於同主機反向代理，Jitsi 官方 Docker 指南建議在 Jitsi 容器內停用 HTTPS，避免其內部 Web 連接埠暴露，並將請求轉送到容器的 HTTP 入口。代理還必須支援 WebSocket 轉發/xmpp-websocket。典型的 Jitsi 端環境如下：

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

然後，在您的反向代理上終止受信任的憑證。當一個代理人管理多個應用程式的憑證時，這種方法更為合適。但這並非更改外部可見網域的理由PUBLIC_URL；使用者仍然應該看到最終的 HTTPS 網域。

追蹤自訂域故障

編輯 .env 檔案後，舊網域仍然存在。

docker compose down使用以下命令重新建立容器docker compose up -d：。另外，請確認您已編輯.env您正在啟動的 Compose 專案所使用的檔案。

HTTPS憑證驗證失敗

確認 DNS A/AAAA 記錄指向接收質詢的伺服器，並且在使用內建的直接憑證流程時，公網連接埠 80 可存取。docker compose logs web在發出另一個請求之前，請檢查 ACME 錯誤的具體情況。

頁面加載成功，但參與者沒有音訊或視訊。

檢查 UDP 10000 端口，對於 NAT 部署，請設定正確的 NAT 值JVB_ADVERTISE_IPS。請記住，反向代理程式處理 Web 流量，它不會取代 Videobridge 媒體路徑。

瀏覽器可以正常工作，但行動應用程式拒絕連接伺服器。

檢查證書鏈。 Jitsi Docker 手冊指出，行動應用程式無法使用預設的自簽名憑證。請使用公鑰證書，或採用應用程式可接收受信任憑證鏈的基礎架構設計。

最終核查清單

• meet.example.com解析到預期的公共位址。
• PUBLIC_URL=https://meet.example.com與瀏覽器網址列完全相符。
• TLS憑證是受信任的，並且涵蓋了meet.example.com。
• 連接埠 80/TCP 和 443/TCP 可用於直接設定。
• UDP 10000 到達 Jitsi Videobridge 主機。
• JVB_ADVERTISE_IPS當伺服器位於 NAT 之後或需要明確通告位址時，此方法正確。
• docker compose ps顯示所需的容器正在運作。
• 一項雙人測試成功發送了音訊和視訊。

一旦這些檢查通過，自訂網域不僅指向 Jitsi，而且還針對實際會議中真正重要的部分進行了配置：HTTPS、訊號和媒體傳輸。

官方參考資料

• Jitsi Meet 自託管指南 — Docker
• docker-jitsi-meet env.example
• 官方 docker-jitsi-meet 倉庫