停止程式碼編輯會話在 10 分鐘時結束

如果 CODE 文件在大約 10 分鐘後穩定斷開連接，請先檢查 WebSocket 路徑經過的每個反向代理或負載平衡器。 600 秒的空閒逾時通常是一個配置問題，但僅憑時間並不能證明是代理導致的；在更改設定之前，請檢查是哪個元件關閉了連接。在大多數部署中，實際的解決方法是保留 Collabora WebSocket 升級，並將代理程式的讀取和發送逾時時間設定為比預期最長編輯會話時間更長。

首先，確認斷線位置。

Collabora Online 使用瀏覽器連接到 CODE 伺服器，而文件整合則依賴與主機（例如 Nextcloud）的 WOPI 通訊。 Collabora 的反向代理指南和 Nextcloud 目前的 Office 範例都記錄了用於文件會話的獨立 WebSocket 路由。如果該路由缺失、發送到錯誤的上游伺服器或受空閒逾時限制，則編輯器可能會失去即時連接，但頁面本身仍然可存取。

這是經過驗證的架構要求。但這並不意味著每次十分鐘一次的故障都是由相同原因造成的：雲端負載平衡器、入口控制器、防火牆、VPN 或其他代理伺服器都可能設定了自己的限制。將可重複出現的時間間隔作為線索，然後在故障發生時檢查訪問日誌和錯誤日誌。

1. 記錄會話中斷的確切時間，以及中斷是發生在正在輸入文字期間還是僅在文件空閒時發生。
2. 在瀏覽器開發者工具中，開啟“網路”面板，篩選“WS”，並檢查路徑以“/”結尾的連線/ws。/cool/記下其狀態，如果瀏覽器報告關閉代碼，則記下關閉代碼。
3. 在同一時間戳，檢查反向代理或入口日誌、CODE 伺服器日誌和 WOPI 主機日誌。尋找代理逾時、上游重設、WebSocket 異常關閉或 WOPI 錯誤。日誌措辭因產品和版本而異，因此不要認為一條訊息是通用的。

如果 WebSocket 連線在配置的 600 秒閾值處終止，請修正擁有該閾值的代理程式或中間伺服器。如果連線在其他時間間隔終止，或日誌顯示 WOPI 或伺服器錯誤，則應根據這些錯誤進行排查。 Nextcloud 的故障排除文件特別建議檢查雙向連接，並查看 Nextcloud 和 Collabora 的日誌。

保持透過代理程式的 WebSocket 連線開啟。

在編輯代理檔案之前，請先確定目前活動的虛擬主機以及 CODE 的實際上遊協定和連接埠。備份配置並驗證語法後再重新載入。以下範例展示了 NGINX 反向代理程式所需的 WebSocket 行為；它並非完整的 Collabora 虛擬主機配置。請將其合併到部署的官方配置中，並保留其其他位置區塊、TLS 設定、URI 處理和安全規則。

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

location ~ ^/cool/(.*)/ws$ {
    proxy_pass https://127.0.0.1:9980/cool/$1/ws;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_read_timeout 36000s;
    proxy_send_timeout 36000s;
}

`--read`和Upgrade` Connection--send` 標頭允許 HTTP 請求切換到 WebSocket。更長的讀取和傳送限制可以防止此代理在較短的預設時間間隔後關閉靜默連線；它們並非用於永久保持會話開啟。請根據您的實際安裝情況調整上游位址和 TLS 驗證，並且不要僅為了讓範例運作而停用憑證檢查。

Collabora 的官方代理範例是完整且符合版本要求的路由配置的權威指南。他們目前的指南包含較長的代理逾時時間；Nextcloud 目前的 Docker 範例也包含專門的/cool/(.*)/wsWebSocket 映射。請使用這些完整的範例，而不是用以下一小段程式碼取代整個虛擬主機：

• Collabora Online 反向代理設置
• Nextcloud 35 Docker 安裝範例

對於 NGINX，nginx -t僅在測試成功後運行並重新載入。對於 Apache，請在重新載入前使用其配置測試。如果 CODE 運行在 Kubernetes Ingress 或雲端負載平衡器之後，更改 CODE 主機上的 NGINX 配置並不能解決 Ingress 或提供者邊緣的逾時問題；請更新日誌中標識的元件。

檢查每一跳網絡，而不僅僅是代碼。

WebSocket 流量可能經過多個中間層：瀏覽器、CDN 或防火牆、外部負載平衡器、入口點、主機代理，然後是代碼層。某一層的較長超時時間不能覆蓋下一層較短的超時時間。請比較每一層的空閒或連線逾時時間，並在平台限制和策略允許的範圍內，將 WebSocket 路由的逾時時間限制設定得比預期的空閒編輯時間更長。

不要將文件的空閒卸載設定與代理程式的網路逾時設定混淆。前者控制何時可以卸載未使用的文件進程；它不會修復中間伺服器已關閉的 WebSocket 連線。同樣，設定過長的逾時時間也無法修復錯誤的升級路由、流量阻塞、HTTP/HTTPS 配置不符或 CODE 進程崩潰等問題。每次更改後，請確認關閉時間是否發生變化或日誌中記錄的原因是否消失；這樣可以縮小責任層級，而不會引入無關的更改。

檢查使用者的瀏覽器和 WOPI 主機是否都能透過 HTTPS 存取 CODE 服務，以及 CODE 服務是否能存取 WOPI 主機。對於 Nextcloud 集成，其故障排除手冊建議先從瀏覽器檢查公共端點/hosting/capabilities，然後從 CODE 伺服器檢查 Nextcloud 狀態端點。這些檢查可以確認基本的連接性，但本身並不能證明已建立的 WebSocket 連線能夠保持十分鐘以上。/hosting/discoverycurl

透過定時會話驗證維修效果

1. 使用其支援的驗證步驟重新載入代理程式或入口配置，然後開啟一個新的文件會話。
2. 保持文件開啟的時間比上次故障的時間更長。先在編輯狀態下測試一次，如果報告的問題發生在非活動狀態下，再在文件處於空閒狀態時測試一次。
3. 確認/cool/.../ws瀏覽器網路面板中的連線保持開啟狀態，且文件繼續透過 WOPI 主機儲存。
4. 查看同一時間段的日誌。測試成功意味著沒有出現匹配的代理程式逾時或意外的 WebSocket 關閉，並且重新開啟文件後編輯內容仍然保留。

如果仍然斷開連接，請恢復記錄的故障時間，並將其與每個躍點的日誌進行比較。入口處 600 秒的斷開連接指向該入口；不同的斷開時間或伺服器端錯誤則指向其他位置。僅憑「10 分鐘」無法確定確切原因，而且不同代理產品和版本的逾時名稱和預設值各不相同。請記錄目前可用的配置（包括 CODE 版本和代理產品），以便將來升級時可以對照當前的官方範例進行檢查。