科技 · 实用指南
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 仍循环，请携带保留的完整日志升级反馈。提供最小可复现主机配置并删去秘密信息；不要公开不必要的主机名、用户名、令牌或私有路径。
