Tecnología · GUÍA PRÁCTICA
¿Remote SSH de VS Code descarga el servidor una y otra vez? Audita el bucle antes de borrar
Repetir la descarga indica que el arranque anterior no fue aceptado, no que debas borrar todas las instalaciones. Conserva el registro completo, vincúlalo al commit exacto de VS Code y comprueba por separado descarga, extracción, inicio y túnel antes de corregir el fallo demostrado.
Cuando Remote-SSH descarga VS Code Server repetidamente, resulta tentador vaciar el directorio remoto de instalación. Puedes perder precisamente el registro y la instalación funcional de un commit que permitirían identificar un fallo de red, una herramienta ausente, falta de espacio, propiedad incorrecta, extracción, salida de inicio o reenvío SSH. La repetición solo demuestra que el cliente no aceptó el arranque anterior; no identifica dónde falló.
Trata un único intento controlado de conexión como una auditoría. Anota el commit del cliente y la ruta remota que aparece en el registro de Remote-SSH, conserva la evidencia y recorre el arranque en orden. Una reparación solo tiene fundamento cuando se conocen tanto la última etapa correcta como la primera etapa fallida.
Fija un intento antes de cambiar nada
Abre el canal de salida de Remote-SSH, muestra el terminal de inicio de sesión si puede haber avisos ocultos y realiza un intento. Guarda toda la salida antes de repetir. Registra el alias del host, versión y commit local de VS Code, versión de la extensión, plataforma y arquitectura remotas, ruta de instalación, vía de descarga, nombre del archivo o commit y error final. Una captura de la última línea es insuficiente: la transición relevante puede estar mucho antes.
El commit forma parte de la identidad. Tras actualizar el cliente puede ser normal necesitar otra compilación del servidor; repetir la descarga para el mismo commit indica que la instalación o su aceptación no terminó. El problema #11269 documenta el coste en conexiones lentas y explica por qué vaciar carpetas indiscriminadamente puede convertir un fallo diagnosticable en otra transferencia completa.
Antes de tocar el árbol del servidor, haz un inventario de solo lectura y usa, si está disponible, la ruta exacta del registro. `df -h "$HOME"`, `df -i "$HOME"`, `id` y `find ~/.vscode-server -maxdepth 4 -type d -print 2>/dev/null` permiten observar bloques llenos, inodos agotados, propiedad inesperada e instalaciones de varios commits sin modificarlas.
Etapa 1: comprueba shell y requisitos
Prueba una sesión no interactiva con el mismo destino SSH; no dependas solo de un inicio interactivo que puede cargar otros archivos. Ejecuta `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'` y conserva la salida junto al registro. Si falta Bash, tar o ambas herramientas de descarga, o el entorno no es compatible, falla un requisito; descargar otra vez el mismo archivo no lo resuelve.
Comprueba si los archivos de inicio no interactivo imprimen carteles, depuración o errores antes de los marcadores de arranque. La antigua pregunta de Stack Overflow sobre análisis del puerto remoto muestra que SSH normal puede funcionar mientras Remote-SSH no interpreta la salida estructurada. Limita la salida decorativa al shell interactivo y repite un solo intento controlado.
Si shell y herramientas funcionan, no vuelvas a cambiarlos sin motivo. Marca la etapa como demostrada y continúa. Una auditoría reduce la búsqueda en lugar de acumular ajustes ajenos al fallo.
Etapa 2: elige y demuestra la vía de descarga
Cuando el host remoto descarga el servidor, necesita acceso HTTPS a `update.code.visualstudio.com` y `vscode.download.prss.microsoft.com`. Comprueba DNS y TLS desde el remoto con una herramienta disponible, interpretando cuidadosamente el estado HTTP. Primero se verifica resolución, ruta y negociación del certificado; la dirección básica de un sitio no debe confundirse con la URL del archivo.
Si la salida remota está bloqueada pero el equipo local puede descargar, configura `"remote.SSH.localServerDownload": "always"` en los ajustes de usuario del VS Code local para descargar y transferir. Es un ajuste de la extensión que puede afectar a otros destinos SSH: registra y restaura su valor anterior. Si el registro ya muestra transferencia local, revisa esa operación y su destino, no el proxy remoto. Si la descarga remota funciona, forzar transferencia añade otra etapa.
El porcentaje de progreso no demuestra instalación. Registra si terminó la descarga, existe el archivo de destino y la salida avanzó a la extracción. Una descarga repetida sin marcador de extracción sigue perteneciendo a descarga o transferencia; un fallo posterior a la descarga completa pertenece a la siguiente etapa.
Etapa 3: verifica espacio, propiedad y extracción
Puede haber gigabytes libres en el directorio personal y ningún inodo disponible. Revisa tanto `df -h` como `df -i` y después la propiedad del directorio padre del servidor y de la ruta exacta del commit. No cambies recursivamente la propiedad de toda la cuenta. Corrige solo una ruta cuya propiedad errónea esté demostrada y averigua antes cómo se produjo.
Si el archivo existe, comprueba que tar se ejecuta y que el destino de extracción del registro admite escritura. Conserva los directorios parciales hasta documentar su commit y fallo. La distribución de archivos cambia entre generaciones de Remote-SSH; usa la ruta del registro actual y no supongas que todos los hosts utilizan `bin/<commit>`.
Una extracción fallida tras una transferencia correcta no se arregla descargando otra vez. Resuelve el problema demostrado de espacio, inodos, permisos o tar y repite una vez con el mismo commit. La transición esperada es pasar del archivo presente al árbol del servidor poblado y al comando de arranque.
Etapa 4: separa el inicio del servidor del reenvío
Después de extraer, localiza el comando de inicio y la salida estructurada. Si el proceso termina antes de comunicar un extremo de escucha, conserva su estado de salida y el stderr cercano. Examina el entorno remoto que recibe realmente, incluidos permisos temporales y salida de scripts de inicio. No lo clasifiques como fallo del túnel hasta demostrar que el servidor arrancó.
Si aparece un extremo de escucha pero el cliente no puede utilizarlo, pasa al reenvío SSH. La documentación distingue AllowTcpForwarding para TCP y AllowStreamLocalForwarding para sockets Unix. Pide al administrador que compruebe la política correspondiente al modo real. `remote.SSH.useLocalServer: false` permite comparar errores ocultos por la vía del servidor local; no concede permiso de reenvío.
El mensaje 'failed to parse remote port' es una pista de clasificación, no una causa universal. Compara la salida guardada con los marcadores esperados: texto sobrante del shell, salida prematura del servidor y túnel bloqueado necesitan reparaciones distintas.
Aplica la reparación mínima que puedas justificar
Prefiere cambios reversibles: completar requisitos, elegir una vía de descarga funcional, liberar espacio confirmado como innecesario, corregir la propiedad de una ruta exacta, ajustar salida no interactiva o solicitar la política de reenvío necesaria. Después de cada cambio, prueba una vez y registra si se desplazó la primera etapa fallida.
El comando oficial Kill VS Code Server on Host puede ayudar con una instancia verdaderamente atascada, pero es una acción de recuperación amplia, no un sustituto del diagnóstico. Antes de usarlo, guarda la salida completa y determina si también eliminaría una instalación funcional de otro commit.
Si demuestras que una instalación de un commit concreto está incompleta, cierra primero sus ventanas remotas y confirma que ningún proceso del servidor ni otra sesión usa esa instancia. Conserva los registros y aísla únicamente el directorio identificado con precisión, sin borrar todo `.vscode-server`. Reconecta una vez con el mismo commit del cliente y confirma la instalación nueva. Mantén lo aislado hasta asegurar el estado funcional y los registros. Una ruta ambigua o una sesión paralela activa obliga a detenerse.
Define el éxito para que el bucle no quede oculto
Una sola ventana que abre no basta. Desconecta y reconecta con el mismo commit local. La segunda conexión debe reutilizar el servidor instalado en lugar de transferir otra vez todo el archivo. Abre un terminal remoto, ejecuta un comando inocuo y comprueba que el host remoto de extensiones mantiene la conexión.
Conserva una fila de auditoría con hora, commit del cliente, plataforma y arquitectura remotas, vía elegida, ruta, bloques e inodos disponibles, versiones de requisitos, última etapa correcta, reparación, resultados del primer y segundo intento y presencia de otra descarga completa. Así una recurrencia permite comparar en lugar de volver a borrar y reintentar.
Si el mismo commit sigue en bucle después de superar las etapas observables, comunica el problema con el registro completo conservado. Incluye la configuración mínima reproducible del host y oculta secretos. No publiques nombres de host, usuarios, tokens ni rutas privadas innecesarios para explicar el fallo.
