修復 Jitsi Meet “您已斷開連線” 連線中斷問題

Jitsi Meet 通話可能會顯示「您已斷開連線」的提示，原因可能是會議的訊號連線中斷、WebRTC 媒體流量無法到達視訊橋接器，或本機網路或瀏覽器中斷了會話。首先檢查問題是影響一位參與者還是所有參與者。這通常可以幫助您判斷是否應該排查設備和網路故障，還是應該排查 Jitsi 伺服器故障。

快速分診檢查清單

你所觀察到的	首先檢查	可能需要調查的區域
只有一個人斷開了連線。	從其他網路或裝置重新加入	參與者的 Wi-Fi、VPN、瀏覽器、應用程式或本地防火牆
多人同時斷開連接	詢問他們是否使用同一家 Jitsi 主機	伺服器、反向代理、防火牆、網際網路連線或服務故障
會議仍在進行，但音訊/視訊卡頓	短暫關閉攝影機，檢查音訊是否恢復。	媒體路徑、頻寬、UDP過濾或設備負載
斷線問題只發生在一家公司或學校網路上。	使用已驗證的熱點重複一次	網路策略、代理、VPN 或 WebRTC 流量被阻止
伺服器或代理變更後問題開始出現。	檢查最近的設定和服務日誌	自託管 Jitsi 訊號、TLS、NAT 或防火牆設置

不要一次性更改多個設定。先測試一項更改，如果可能，重新加入同一會議，並注意症狀是否發生變化。

首先確定是哪個連線失敗了。

Jitsi Meet 使用 WebRTC 實現即時音訊和視訊。會議的順利進行不僅取決於頁面載入：瀏覽器必須與伺服器保持通信，並建立到 Jitsi Videobridge 的媒體路徑。有時，與會者可能仍顯示在會議室中，但媒體畫面卻會卡頓；完整的「您已中斷連線」訊息可能表示整個會話或通訊中斷。僅憑該訊息無法確定確切的根本原因。

記下掉線時間、瀏覽器是否顯示重連提示、其他與會者是否受到影響，以及會議是在 meet.jit.si 還是在 Jitsi 私有域上舉辦。切勿公開發布私有會議 URL、房間名稱、存取權杖或未經編輯的日誌。

使用瀏覽器檢查參與者

1. 請重新連接並確認會議鏈接

如果螢幕上出現重新連線提示，請使用該提示。如果會議仍然無法恢復，請在新分頁中重新開啟原始邀請連結並重新加入。確認會議室名稱和主持人網域與邀請函一致；拼字錯誤或連結失效可能會導致連接到不同的會議室或主持人。如果所有與會者都已斷開連接，請稍等片刻，並詢問會議組織者服務是否仍然可用，然後再反覆刷新頁面。

2. 測試支援的、已更新的瀏覽器

更新瀏覽器，完全退出，然後重試會議。如果仍然斷開連接，請嘗試使用 Jitsi 支援的其他瀏覽器。 Jitsi 的瀏覽器支援清單列出了瀏覽器支援和平台說明；請查看該頁面，因為支援詳情可能會有所變更。在 iPhone 和 iPad 上，不同品牌的瀏覽器使用相同的底層瀏覽器引擎，因此嘗試其他品牌的瀏覽器可能無法確定是瀏覽器引擎的問題。

為了進行更清晰的對比，請嘗試使用隱私視窗或暫時停用過濾腳本、封鎖追蹤器或修改網路請求的擴充功能。如果這樣可以解決通話問題，請逐一重新啟用擴充功能以找出衝突所在。切勿將安全保護措施禁用作為永久性的權宜之計。

3. 比較網絡

靠近 Wi-Fi 存取點，暫停大型下載或雲端備份，然後在您有權使用的另一個網路上進行一次測試。使用手機熱點可以幫助您區分家庭或工作場所網路問題與瀏覽器或伺服器問題。如果 Jitsi 在另一個網路上可以正常工作，但在原來的網路上反覆斷開連接，請將測試時間告知網路管理員，並詢問是否對即時 WebRTC 流量進行了過濾。

VPN、代理、強制入口網站或防火牆可能會中斷訊號或媒體傳輸。如果您的組織要求使用 VPN，請勿繞過其策略；請諮詢 IT 部門，以確認 Jitsi 主機是否被允許。如果允許您在 VPN 斷開連線的情況下進行比較，請僅短暫進行，並在之後重新啟用 VPN。

4. 檢查設備和應用程式狀況

在手機上，測試期間請將 Jitsi 應用程式或瀏覽器保持在前台運行，如果裝置允許，請為此測試停用省電模式。行動作業系統可能會暫停後台網路活動。此外，請檢查應用程式和作業系統是否已更新，如果連線仍然失敗，請重新啟動裝置。麥克風或攝影機權限問題通常會影響設備訪問，而不是網路斷開，因此請分別處理這些症狀。

當音訊/視訊故障但會議頁面仍然打開時

暫時關閉攝影機，看看音訊是否恢復穩定。這可以減少頻寬佔用，但無法修復伺服器路由故障。如果音訊和視訊在同一網路上同時故障，但在其他網路上正常，請檢查防火牆或 NAT 限制。 Jitsi 的自託管指南指出，TCP 443 用於一般 Web 訪問，UDP 10000 用於普通音頻/視頻會議，TCP 5349 用於 UDP 被阻止時的 coturn 回退；可選的 STUN 功能可能還會用到 UDP 3478。這些是伺服器端部署要求，並非參與者需要在個人裝置上開啟的連接埠。請參閱最新的Jitsi 防火牆和 NAT 指南。

如果會議在其他連線下可以正常運行，請將此對比結果報告給網路管理員。請他們檢查組織中關於 Jitsi 主機名稱和 WebRTC 流量的規則，而不是要求全面關閉防火牆。

檢查是否存在自架的 Jitsi 管理員

確認可及性和媒體路徑

驗證公網 DNS 名稱是否解析到預期伺服器，TLS 憑證是否有效，以及所需流量是否到達正確的主機。如果伺服器位於路由器或雲端防火牆之後，請檢查主機防火牆以及上游安全群組或連接埠轉送規則。如果雲端防火牆仍然阻止相同的流量，則 UFW 中的規則無效。

sudo ufw status verbose
sudo ss -lntup

這些命令顯示的是本地防火牆規則和監聽套接字；但它們並不能證明外部參與者可以存取該服務。請從外部網路進行測試，並確認路由器或服務提供者是否將相關流量轉送至 Jitsi Videobridge。 Jitsi 指出，如果從外部無法撥打電話，則位於 NAT 後面的部署可能需要正確的公網位址和本地位址對應。

檢查 TLS、反向代理和 Docker 設定

對於反向代理部署，請驗證 HTTPS 是否正常運作，以及代理程式是否正確轉送 WebSocket 訊號。 Docker 官方指南在其 Nginx 範例中記錄了/xmpp-websocket所需的路由和標頭。如果代理程式能夠提供頁面服務但丟棄了 WebSocket 連接，則可能導致使用者無法保持會議會話。

使用 Docker Compose 時，請確保其PUBLIC_URL與訪客實際使用的公共網域名稱匹配，並且發布的主機連接埠與您的防火牆和代理設定相符。 Jitsi 指南警告說，直接透過 HTTP 而不是 HTTPS 提供實際會議服務可能會導致 WebRTC 問題。請避免在未檢查您執行的 Jitsi 版本和部署方法的情況下，從其他 Jitsi 版本複製設定片段。

將伺服器日誌與事件發生時間進行關聯

將斷開連線的時間與服務日誌進行比較。在 Debian 或 Ubuntu 軟體包安裝中，Jitsi 會記錄日誌文件，包括 `<log_file>` /var/log/jitsi/jvb.log、/var/log/jitsi/jicofo.log`<log_file>` 和/var/log/prosody/prosody.log`<log_file>`。 Docker 部署透過容器儲存日誌，因此請檢查相關容器的輸出以及已安裝版本的設定目錄。

sudo tail -n 150 /var/log/jitsi/jvb.log
sudo tail -n 150 /var/log/jitsi/jicofo.log
sudo tail -n 150 /var/log/prosody/prosody.log

在事件發生時間戳附近搜尋服務重新啟動、橋接註冊變更、WebSocket 故障、憑證錯誤或重複連線逾時等情況。共享日誌前，請隱去參與者識別碼、房間名稱、IP 位址和令牌等資訊。 Debian /Ubuntu 自託管指南也建議嘗試使用其他瀏覽器、檢查 WebRTC 支援以及檢查防火牆/NAT 規則，作為基本的偵錯步驟。

升級檢查清單

記錄 Jitsi 主持人、大致時間戳記和時區、裝置、作業系統、瀏覽器或應用程式版本，以及該問題影響的是一個人還是整個會議。
注意觀察使用不同的瀏覽器或網路是否會改變結果。
對於自託管伺服器，請包含最近的代理程式、防火牆、DNS、憑證或 Jitsi 升級。
僅分享必要的最低限度診斷信息，並刪除私人房間詳情和憑證。
如果使用 meet.jit.si 或其他託管主機，請將報告傳送給會議組織者或服務支援；參與者無法變更該主機的防火牆或伺服器設定。

如何確認修復已完成

使用原始設備和網路加入測試會議，保持連接足夠長的時間以涵蓋通常發生故障的時間段，並確認音訊和視訊功能仍然可用。如果問題影響到所有與會者，請換一位與會者重複上述步驟。對於自託管部署，請驗證瀏覽器訊號以及來自伺服器網路外部的媒體檔案。僅成功加載頁面是不夠的；會議連接應保持穩定，且與會者應能夠交換音訊和視訊。