如何在 Jitsi Meet 中停用遙測和資料記錄

如果您是 Jitsi Meet 的託管用戶，您可以關閉該應用程式的分析處理程序並封鎖其可選的第三方要求config.js。這會減少客戶端遙測數據，但不會關閉 Web 伺服器、Docker、Prosody、Jicofo 或 Videobridge 的日誌。這些是獨立的資料路徑，由伺服器營運商管理。如果您透過 Jitsi Meetmeet.jit.si或其他託管服務加入會議，則無法自行變更其伺服器端設定。

截至 2026 年 10 月 6 日，目前的 Jitsi 配置參考文件仍記錄了相關analytics.disabled控制項disableThirdPartyRequests。近期產品變更並未導致需要更改配置步驟。以下步驟適用於自架 Web 部署；行動 SDK、嵌入式整合和第三方託管面板可能提供不同的控制項。

一個類似 Jitsi 的瀏覽器會議大廳，包含房間名稱、「加入會議」按鈕以及麥克風和攝影機控制按鈕。 — 會議大廳是面向使用者的客戶端；其分析選項由主機提供的配置控制。

Jitsi Meet 中的「遙測」和「日誌記錄」分別是什麼意思？

Jitsi 的 Web 用戶端可以載入分析處理程序或連線到已設定的外部統計服務。配置包括一個全域分析禁用標誌以及 rtcstats 等服務的選項。另一個隱私設定disableThirdPartyRequests會阻止第三方請求，並導致頭像在本地生成；Jitsi 指出，啟用此設定後，外部統計整合將無法正常運作。

WebRTC 會議仍然需要交換訊號和媒體流量才能正常運作。停用分析功能並不會隱藏使用者的網路位址（使其不被會議基礎設施存取），也不會將與會者從會議室中移除、阻止主持人錄製會議或刪除已收集的資料。伺服器存取日誌和診斷日誌也獨立於瀏覽器分析功能。 Jitsi 的日誌分析器指南描述了一個獨立的堆疊，該堆疊可以透過 OpenTelemetry 和 Loki 收集元件日誌，這說明了為什麼一個客戶端設定無法停用所有日誌。

1. 確認部署控制權歸屬

對於您管理的 Jitsi 伺服器，請尋找其 Web 設定檔。在常見的 Debian 或 Ubuntu 軟體包安裝中，該檔案通常位於 `/etc/jitsi.conf` /etc/jitsi/meet/<your-domain>-config.js。使用 Docker 時，主機檔案通常會掛載到 Web 容器中作為其 `/etc/jitsi.conf` config.js；請在您自己的 Compose 配置中使用對應的路徑和磁碟區對應。編輯前請務必備份文件，並保留其現有結構。

如果您僅使用公共會議或供應商主辦的會議，用戶端可能可以選擇限制自身資訊的公開，但伺服器日誌記錄、資料保留和分析由主辦單位決定。如果您重視隱私和資料保留設置，請向服務提供者諮詢其目前的隱私和資料保留詳情。

2. 停用客戶端分析和外部請求

在現有的頂級config物件中，將這些條目合併到符合的位置。不要貼上現有按鍵的第二個副本，也不要替換整個設定檔：

disableThirdPartyRequests: true,
enableDisplayNameInStats: false,
enableEmailInStats: false,
gatherStats: false,
analytics: {
  disabled: true,
  rtcstatsEnabled: false,
  rtcstatsStoreLogs: false,
  scriptURLs: []
},

分析選項嵌套在 `<path>` 下analytics；其他四個條目位於頂層。如果您的文件已包含analytics對象，請編輯該對象，而不是新增對象。刪除您有意配置的任何自訂分析腳本 URL 和服務端點，或像圖中所示那樣將陣列留空。明確的 `rtcstats` 值可以清楚地顯示預期狀態，而 `<path>`analytics.disabled是分析處理程序的主要開關。

Jitsi 的高級使用者指南也disableThirdPartyRequests: true將其列為配置選項。它可能會影響依賴外部服務的功能，包括外部託管的頭像或統計資訊整合。在廣泛部署變更之前，請先測試貴組織使用的會議功能。

一個暗黑程式碼編輯器，顯示了一個包含分析設定部分的 Jitsi config.js 檔案。 — 相關設定應位於現有的 config.js 物件中；程式碼編輯器視圖僅供參考，並非特定安裝的螢幕截圖。

3. 套用變更並檢查已部署的配置

儲存文件，然後按照部署的正常流程重新載入或重新啟動 Web 元件。對於 Docker 來說，這通常意味著在確認主機掛載的設定檔是您編輯的檔案後，重新建立或重新啟動 Web 服務；基於軟體包的部署可能會直接提供該檔案。 Jitsi 的安裝方式因軟體包、版本和本地修改而異，因此不要習慣性地重新啟動每個元件。

在隱私瀏覽視窗中開啟會議頁面或清除網站緩存，然後檢查實際發送到瀏覽器的配置。在開發者工具中載入https://your-domain/config.js並確認配置中包含您設定的值。如果顯示的是舊值，請檢查特定於網域的檔案名稱、容器磁碟區掛載、反向代理程式緩存，以及瀏覽器是否連接到目標伺服器。

4. 單獨審查伺服器端日誌。

現在清點一下仍然存在的日誌。常見的日誌位置包括反向代理存取日誌和錯誤日誌、Docker 容器輸出，以及來自 Prosody、Jicofo 和 Jitsi Videobridge 的日誌。如果您安裝了選購的日誌分析器堆疊，也請檢查其 OpenTelemetry Collector 和 Loki 配置。 Jitsi 的日誌分析器文件將該收集器和儲存路徑與用戶端分析分開描述。

選擇一種操作策略，而不是假設所有日誌都可以安全地停用。您可以降低日誌詳細程度、限制對日誌的存取、縮短日誌保留期限，或關閉選購的日誌傳輸管道。保留足夠的診斷資訊以調查故障和濫用行為，除非有明確的需求，否則避免收集房間名稱、電子郵件地址、IP 位址或完整的信令資料。在實際儲存層（例如代理程式、容器執行時間或日誌後端）套用日誌保留策略，因為用戶端config.js不會設定這些保留期限。

伺服器管理介面，顯示正在執行的 Jitsi 容器和一個顯示 Web 服務請求日誌的終端。 — 停用瀏覽器分析後，容器和 Web 伺服器日誌仍然是一個獨立的管理問題。

5. 驗證行為，不要將網路面板靜默狀態視為證據

使用全新的瀏覽器工作階段加入測試房間，並確認音訊、視訊、聊天和螢幕分享功能仍然正常。在瀏覽器的網路面板中，查看會議開始和進行期間對第三方分析或統計伺服器的請求。某些請求是會議本身所必需的，屏蔽所有不熟悉的伺服器名稱可能會導致訊號、媒體設定、頭像或其他整合故障。將目標伺服器與您自己的配置和部署設計進行比較；在一次測試中未發現可見的請求並不表示伺服器日誌沒有被寫入。

Jitsi 式的即時會議，旁邊是瀏覽器開發者工具網路面板清單頁面和腳本請求。 — 使用「網路」面板尋找已設定的外部分析請求，同時保持呼叫所需的連線。

如果異常流量仍然存在，請檢查其他來源：自訂分析腳本、反向代理注入的標籤、iframe 父頁面、瀏覽器擴充功能或主機提供者本身的偵測工具。如果問題出在伺服器日誌而非客戶端分析上，請檢查相關的服務和儲存配置。

這項改變能保證什麼，又不能保證什麼？

這些設定可用於停止 Jitsi Meet 在您控制的伺服器上配置的用戶端分析和可選的第三方請求。它們不會提供匿名性，也不會停用所有網路連線或自動刪除歷史資料。此外，它們也無法控制由修改後的版本、嵌入網站或託管服務提供者所新增的遙測資料。請針對您部署的 Jitsi 版本檢查配置，並在升級後重新檢查，因為配置名稱和整合可能會變更。

有關主要參考資料，請參閱Jitsi Meet 設定指南、進階使用者指南、上游 config.js 範例和 Jitsi自託管日誌分析器指南。