科技 · 實用指南
VS Code Remote SSH 反覆下載伺服器？先定位安裝循環，再清理檔案
反覆下載只代表啟動未被接受，不能證明所有舊安裝都應刪除。保留完整日誌，綁定準確的 VS Code commit，分別核對下載、解壓縮、啟動與轉送，只修復有證據的失敗環節。
Remote-SSH 不斷下載 VS Code Server 時，很容易直接清空遠端安裝目錄。但這可能一併刪掉能解釋問題的日誌與仍可運作的 commit 安裝。實際故障可能在網路、缺少工具、空間不足、擁有者、解壓縮、啟動輸出或 SSH 轉送。重複下載只代表用戶端未接受上一輪啟動，無法指出哪一步失敗。
把一次受控連線當作稽核。記錄用戶端 commit 與 Remote-SSH 日誌列出的遠端路徑，保留證據，再依序檢查啟動鏈。只有同時確認最後成功與第一個失敗的環節，修復才有依據。
變更前先固定一次連線證據
開啟 Remote-SSH 輸出通道；若登入提示可能被隱藏，啟用登入終端機，再連線一次。重試前保存完整輸出，記下主機別名、本機 VS Code 版本與 commit、Remote-SSH 擴充功能版本、遠端平台與架構、安裝路徑、下載路線、封存檔或 commit 名稱及最後錯誤。只截最後一行不夠，關鍵轉折可能早已出現。
commit 是安裝身分的一部分。用戶端更新後要求另一個伺服器建置可能正常；相同 commit 反覆下載則表示安裝或接受流程未完成。議題 #11269 顯示慢速連線上的成本，也說明清空所有目錄可能把可診斷的問題變成又一次完整傳輸。
動到伺服器目錄前先唯讀盤點，優先採用日誌列出的準確路徑。`df -h "$HOME"`、`df -i "$HOME"`、`id` 與 `find ~/.vscode-server -maxdepth 4 -type d -print 2>/dev/null` 可協助找出區塊空間、inode、擁有者及多個 commit 安裝，不修改檔案。
環節一：證明 shell 與必要工具可用
透過相同 SSH 目標做非互動測試，不只依賴可能載入不同啟動檔的互動登入：`ssh your-host 'printf "shell-ok\n"; command -v bash; command -v tar; command -v curl || command -v wget; uname -s; uname -m; getconf GNU_LIBC_VERSION 2>/dev/null || true'`。輸出與連線日誌一併保存。缺少 Bash 或 tar，curl 與 wget 均不可用，或執行環境不受支援，是必要條件失敗，重新下載同一封存檔無法解決。
檢查非互動啟動檔是否在啟動標記前印出橫幅、除錯文字或錯誤。長期存在的 Stack Overflow 連接埠解析問答顯示，即使一般 SSH 可用，Remote-SSH 仍可能無法解析結構化啟動輸出。讓裝飾性輸出只在互動 shell 出現，再做一次受控連線。
shell 與工具通過後，不再反覆調整。把此環節標為已證明，再繼續。有效稽核應縮小範圍，不應累加無關設定。
環節二：選擇並證明下載路線
遠端自行下載伺服器時，需要透過 HTTPS 存取 `update.code.visualstudio.com` 與 `vscode.download.prss.microsoft.com`。以遠端現有工具檢查 DNS 與 TLS，謹慎解讀 HTTP 狀態：先證明名稱解析、路由與憑證協商，別把網站首頁當成封存檔下載網址。
若遠端對外連線受阻、本機卻能下載，在本機 VS Code 使用者設定加入 `"remote.SSH.localServerDownload": "always"`，選擇本機下載後傳輸。這是擴充功能層級設定，可能影響其他 SSH 目標，應記錄並還原原值。若日誌已顯示本機傳輸，就檢查傳輸與目的位置，不要改遠端代理。遠端下載正常時，強制傳輸會增加一個環節。
進度百分比不等於安裝成功。記下封存檔是否下載完成、目標檔案是否存在，以及日誌是否進入解壓縮。一直下載卻沒有解壓縮標記，問題仍在下載或傳輸；下載完成後才報錯，就進入下一環節。
環節三：核對空間、擁有者與解壓縮
家目錄仍有數 GB 空間，也可能已用完 inode。同時檢查 `df -h` 與 `df -i`，再查看伺服器父目錄與準確 commit 路徑的擁有者。不要遞迴更改整個帳號的擁有權；只處理已證明歸屬錯誤的路徑，並先查明成因。
封存檔存在時，確認 tar 能執行、日誌中的解壓縮目標可寫。記錄 commit 與失敗情況前保留未完成目錄。Remote-SSH 目錄結構隨版本變化，應使用當前日誌列出的路徑，不假設所有主機都是 `bin/<commit>` 結構。
成功傳輸後的解壓縮錯誤，重複下載無法修好。處理已證實的空間、inode、權限或 tar 問題，再以同一 commit 重試一次。預期進展是從封存檔已存在，走到伺服器目錄已填入檔案並出現啟動命令。
環節四：區分伺服器啟動與 SSH 轉送
解壓縮成功後找出啟動命令及伺服器結構化輸出。若程序尚未報告監聽端點就結束，保存結束狀態及附近標準錯誤。檢查它實際取得的遠端環境，包括暫存目錄權限與啟動指令碼輸出。在伺服器確實啟動前，不把問題歸為通道故障。
伺服器已報告監聽端點、用戶端卻無法使用時，才檢查 SSH 轉送。官方排障區分 TCP 模式的 AllowTcpForwarding 與 Unix socket 模式的 AllowStreamLocalForwarding。請管理員核對實際端點模式的政策。`remote.SSH.useLocalServer: false` 可用來比較被本機伺服器路徑隱藏的錯誤，但不會授予轉送權限。
「failed to parse remote port」是分類線索，不是通用根因。將已保存輸出與預期啟動標記對照：多餘 shell 文字、伺服器提前結束及通道被阻擋，需要不同修復。
採用有證據支持的最小修復
優先選擇可逆變更：補齊必要工具、採用可行下載路線、清理已確認不需要的空間、修正準確路徑的擁有者、調整非互動 shell 輸出，或請管理員提供所需轉送政策。每改一項只連線一次，記下首個失敗環節是否改變。
官方 Kill VS Code Server on Host 命令對確實卡住的實例有幫助，但屬於範圍較大的恢復動作，不能代替診斷。使用前保存完整輸出，確認是否也會移除仍能工作的其他 commit 安裝。
只有證明某個準確 commit 安裝不完整後，才先關閉相關遠端視窗，確認沒有伺服器程序或其他工作階段使用該實例。保留日誌，再只隔離已準確對應的目錄，不清空整個 `.vscode-server`。以同一用戶端 commit 再連線一次，確認新安裝；在工作狀態與日誌安全保存前，保留隔離副本。路徑不明或其他工作階段仍活動時，就停止。
定義完成條件，避免循環被掩蓋
一次視窗連線成功還不夠。中斷後以同一本機用戶端 commit 再連線，第二次應重用已安裝伺服器，不再完整傳輸封存檔。開啟遠端終端機執行無害命令，確認遠端擴充功能宿主持續連線。
留下一列稽核紀錄：時間、用戶端 commit、遠端平台與架構、下載路線、安裝路徑、可用區塊與 inode、必要工具版本、最後成功環節、修復、第一次及第二次連線結果，以及是否再次完整下載。未來復發即可比較，不必又清空重試。
若可觀察的環節都通過、同一 commit 仍循環，請攜帶完整保存的日誌升級回報。提供最小可重現主機設定並遮蔽機密；不要公開不必要的主機名稱、使用者名稱、權杖或私人路徑。
