Fix Nextcloud Talk Video Call Quality and TURN Server Connection

Nextcloud Talk call problems are often described as “bad video quality,” but the underlying causes are not all the same. A user may have enough bandwidth and still fail to connect because a firewall blocks peer-to-peer WebRTC traffic. Another call may connect successfully through TURN but feel slower because all media is being relayed. A larger meeting may struggle even with a perfectly working TURN server because the deployment is still using the built-in peer-to-peer topology instead of the High Performance Backend.

The most useful troubleshooting approach is therefore to separate connectivity, media path, and scalability. As of October 6, 2026, Nextcloud's upstream Talk documentation still describes TURN as the fallback when direct WebRTC connectivity is not possible and recommends port 443 for maximum compatibility. It also notes that a TURN server can still be required when the High Performance Backend is in use. See the official Nextcloud Talk TURN documentation and official coturn setup guidance for Talk.

What should you fix first: bandwidth, TURN, or the High Performance Backend?

Use the symptom pattern to choose the next action instead of changing several settings at once.

Symptom	Most likely area	First action	Trade-off
Call works on one network but fails from a corporate or hotel network	Firewall, NAT, or missing TURN fallback	Verify TURN over UDP/TCP and, where needed, TLS on port 443	Relaying improves reachability but consumes TURN bandwidth and may add latency
Two-person calls are fine, larger calls become unstable	Call topology and client upload/CPU load	Evaluate the Nextcloud Talk High Performance Backend	More infrastructure, but better scaling for multi-participant calls
Video connects but is pixelated or freezes	Packet loss, latency, Wi-Fi, uplink capacity, or overloaded endpoints	Test from a wired or known-good network before changing TURN	TURN cannot create bandwidth that is not available
TURN test fails even though coturn is running	Secret mismatch, firewall, NAT mapping, DNS, or relay ports	Check credentials, public IP mapping, and relay range	Opening a large relay range is simpler; narrowing it reduces exposed ports but requires deliberate capacity planning

Nextcloud Talk 群組通話佈局範例，包含三位參與者和標準通話控制。 — A representative Talk group-call layout. If small calls work but larger calls degrade, investigate topology and endpoint load instead of assuming TURN alone will fix the problem.

Step 1: identify whether the failure is connectivity or media quality

首先進行兩項簡短測試。第一，在簡單的網路環境下（例如普通的寬頻連線），讓兩個客戶端之間進行通話。然後，在受限網路環境下（例如公司 Wi-Fi、VPN 或行動熱點）重複上述步驟。如果僅在受限網路環境下通話失敗，則 TURN 很可能是問題所在。如果兩次通話都能連接，但視訊品質較差，請在更改中繼架構之前收集網路和裝置方面的證據。

Nextcloud 官方記錄的連接順序是：首先嘗試直接的點對點連接，使用 STUN 協定發現可達位址，如果無法建立直接路徑，則依賴 TURN 協定。這意味著TURN 主要是一種連接備用方案，而非通用的視訊品質提升方案。中繼路徑雖然更可靠，但傳輸距離更長，並且會將媒體頻寬轉移到 TURN 伺服器上。

步驟 2：配置 Coturn 以用於 Nextcloud Talk

對於自託管部署，Coturn 是 Nextcloud 文件中最常見的 TURN 實作。 Nextcloud 建議此整合使用共用金鑰驗證。產生一個強隨機金鑰，並在 Coturn 和 Talk 管理設定中使用相同的金鑰值。

openssl rand -hex 32

最小配置通常包括監聽埠、指紋辨識、共用金鑰認證、網域和對等方限制。具體文件位置取決於您的作業系統和軟體包。以下是一個典型的配置範例：

listening-port=443
fingerprint
use-auth-secret
static-auth-secret=REPLACE_WITH_RANDOM_SECRET
realm=turn.example.com
total-quota=0
bps-capacity=0
stale-nonce
no-multicast-peers

舊版的 coturn 可能需要一些新版本不再需要的選項，因此請勿盲目複製舊配置。 Nextcloud coturn 文件會明確標註版本相關的指令。請對照最新的Nextcloud coturn 說明檢查您安裝的 coturn 版本。

如果 Coturn 位於 NAT 之後，請正確設定其公網位址到私網位址的對應。 Coturn 自身的組態參考文件解釋了external-ip映射關係，並要求中繼埠在 NAT 環境下保持一致的對應。請參閱上游 Coturn 範例配置。

終端編輯器顯示了 coturn 配置，其中包含連接埠 443、共用金鑰認證、網域、配額和選購的 TLS 憑證路徑。 — Nextcloud Talk 的 coturn 設定元素範例：連接埠 443、共用金鑰驗證、領域設定和可選的 TLS 憑證路徑。

UDP、TCP 或 TLS：哪一個應該啟用？

對於即時媒體，UDP 通常是首選傳輸協議，因為它避免了 TCP 的重傳行為和隊頭阻塞。然而，一些企業網路和訪客網路會完全屏蔽 UDP。對於僅允許類似 Web 流量的網絡，TCP 或基於 TLS 的 TURN 可以提供可行的備用方案。

為了獲得最佳的可近性，Nextcloud 建議監聽 443 連接埠並支援 TURN/TLS。同時使用這兩種協定turn:可以turns:提高相容性，但也意味著需要管理憑證和額外的傳輸路徑。如果所有使用者都在受控網路中，且已知 UDP 可以正常運作，那麼採用更簡單的 UDP 優先設計可能會更容易操作。如果使用者經常從飯店、客戶現場、封閉辦公室或 VPN 連接，那麼通常值得進行額外的配置以支援 TCP/TLS 回退。

步驟 3：正確開啟監聽器和中繼埠

一個常見的錯誤是只開啟了 TURN 監聽連接埠。客戶端首先透過監聽器聯絡 coturn，但 coturn 也為媒體傳輸分配了中繼端點。 Coturn 的上游預設會使用 UDP 連接埠49152-65535進行中繼分配。如果該連接埠範圍被主機防火牆、雲端安全群組、上游路由器或 NAT 裝置阻止，則身份驗證可能成功，但媒體傳輸仍然失敗。

您可以保留預設的中繼埠範圍，也可以使用 `--relay-range` 和 `--relay-range` 參數來刻意縮小範圍min-port。max-port權衡之道顯而易見：寬範圍操作簡便，且分配容量充足；窄範圍雖然更易於在防火牆策略中描述，但如果並發中繼端口過多，則可能成為容量瓶頸。縮小範圍時，應根據預期並發情況來調整，而不是隨意選擇一個較小的數值。

如果 TURN 主機位於路由器後方並擁有私有位址，則需為所選繼範圍保留一對一連接埠映射，並在 coturn 中設定公網位址映射。如果主機在其介面上直接擁有公用 IP 位址，則無需進行 NAT 對應步驟。

防火牆規則範例，允許 TCP 和 UDP 連接埠 443 以及交叉 UDP 中繼範圍 49152 至 65535 — 針對 coturn 的防火牆規劃：允許 TURN 監聽器和已配置的中繼範圍。所示範圍為 coturn 文件中記錄的預設值，並非強制值。

步驟 4：在 Nextcloud Talk 中新增 TURN 伺服器

開啟 Nextcloud 管理後台，進入 Talk 設定。使用主機名稱和連接埠號碼新增 TURN 伺服器，而不是使用http://URL。 Nextcloudhttps://目前的 Talk 文件指出 TURN 方案是單獨選擇的，因此伺服器欄位應採用以下格式turn.example.com:443：

輸入與 coturn 中配置的相同的共享金鑰，並啟用伺服器實際接受的協定。如果使用 TLS，請選擇對應的 TURN 方案，並確保憑證與 TURN 主機名稱相符。您也可以使用自己的 TURN 服務作為 STUN 伺服器，這樣可以簡化主機管理；不過，如果您需要獨立的故障域或地理位置分散的中繼，將 STUN 和 TURN 分開使用會更有幫助。

請勿在螢幕截圖、工單或公開設定範例中洩漏共用金鑰。 Nextcloud 使用該金鑰為客戶端產生臨時 TURN 憑證。

步驟 5：測試 ICE 候選對象，然後從限制性網路進行測試

儲存通話配置後，請使用管理檢查來驗證 TURN 伺服器是否傳回可用的 ICE 候選位址。如果檢查成功，則表示瀏覽器可以從配置的 TURN 服務中取得可用的候選位址。但這並不意味著每個用戶網路、每條中繼路徑以及每次大型呼叫都能正常運作。

至少從一個受限網路重新發起一次真實呼叫。這一點很重要，因為即使伺服器端檢查通過，用戶網路仍然會阻止 UDP、DNS 解析或特定傳輸方式。如果 UDP 失敗但 443 連接埠上的 TCP/TLS 連線成功，則保留備用路徑。如果所有路徑都失敗，則檢查防火牆日誌、Coturn 日誌、DNS、憑證有效性、共用金鑰和 NAT 對應。

Nextcloud Talk 管理檢查範例，顯示 STUN 和 TURN 狀態成功，且有可用的 ICE 候選對象。 — ICE候選檢查成功是一個強有力的配置訊號，但仍需要從受限網路進行實際呼叫來驗證端到端可達性。

何時應該添加高性能後端？

TURN 和高效能後端分別解決不同的問題。當用戶端無法建立所需的 WebRTC 路徑時，TURN 會轉送流量。高效能後端改變了多參與者媒體的處理方式，使得每位參與者無需向其他參與者單獨上傳資料流。

Nextcloud Talk 介面警告稱，在不使用高效能後端的情況下執行 Talk 僅適用於非常小的通話，通常專案描述為兩到三名參與者。如果問題僅在參與者人數增加時出現，新增 TURN 可能會使更多用戶端可連接，但不會消除點對點上傳和 CPU 負擔。在擴展群組通話之前，請先查看Nextcloud Talk 系統需求和專案的高效能後端指南。

即使使用高效能後端，當使用者從受限網路連線時，也應保持 TURN 可用。 Nextcloud 文件中列出了20000-40000後端預設的 WebRTC 媒體範圍，並特別指出，即使用戶端僅限於連接埠 443，可能仍需要 TURN 將封包轉送到該後端範圍。

自託管 TURN 與託管 TURN

選項	優勢	成本和限制	最佳匹配
自託管 coturn	完全控制，資料路徑盡在您的管理之下，配置可預測。	您負責證書、更新、監控、頻寬、防火牆策略和地理容量的運作維護。	具備基礎設施技能或嚴格管制要求的組織
管理式 TURN	更低的營運成本和可能更容易的地理覆蓋範圍	持續服務費用和媒體可能需要透過第三方中繼提供者傳輸	重視營運簡易性和跨區域覆蓋範圍的團隊
禁止轉彎	當直接使用 WebRTC 時，伺服器成本最低，路徑最短。	在對稱NAT和限制性防火牆的情況下，通話可能會失敗。	在客戶網路已知且經過測試的受控環境中進行測試

實用調校檢查清單

盡可能選擇直接使用 WebRTC。它通常能最大限度地降低中繼成本和延遲。
為了提高可靠性，請使用 TURN 協定。將其作為應對複雜 NAT 和防火牆環境的備用路徑。
優先使用UDP協議，為了相容性，使用TCP/TLS協定。 Nextcloud推薦使用連接埠443作為監聽器，因為它對防火牆最為友善。
開啟中繼範圍，而不僅僅是監聽器。使防火牆和NAT規則與實際min-port配置相符max-port。
監控 TURN 頻寬。中繼通話可能會透過 TURN 主機傳輸大量媒體流量，因此網路容量通常比 CPU 更重要。
將規模問題與連線問題區分開來。對於規模較大的會議，應評估高效能後端，而不是強行增加 TURN 的流量。
在真實用戶網路中進行驗證。雖然需要進行 ICE 測試，但飯店網路、企業網路、VPN 網路和行動網路的表現可能有所不同。

結論

如果 Nextcloud Talk 在某些網路上可以正常運作，但在其他網路上則不行，請設定可正常存取的 TURN 服務，並驗證監聽器、共用金鑰、NAT 對應和中繼連接埠。如果通話連線成功但品質較差，請先測量用戶端網路和終端負載，因為 TURN 可能會增加延遲而不是降低延遲。如果問題隨著參與者數量的增加而加劇，通常更合適的架構解決方案是使用高效能後端，同時保留 TURN 作為受限網路的相容方案。