Un desarrollador trasladó la autenticación de Claude Code a un VDS y mantuvo los proyectos en el Mac

En octubre, numerosos usuarios de Claude en Rusia y países vecinos volvieron a sufrir suspensiones de sus cuentas. El autor del análisis publicado en Habr perdió su suscripción Max un día antes del cobro y, como razonablemente supuso, el soporte no habría resuelto nada. Compró una nueva suscripción y montó una configuración en la que los proyectos permanecen en su Mac, mientras que la autenticación de Anthropic y la salida a la red se alojan en un servidor Linux. Es un experimento personal, y el propio autor subraya que no debe considerarse una guía universal.

Por qué Remote SSH y un proxy sencillo no fueron suficientes

La primera idea era la más evidente: instalar Claude Code en el VDS y conectarse mediante VS Code Remote SSH. Esto funciona, pero los proyectos del Mac no aparecen por sí solos en el servidor. Es posible clonar los repositorios y configurar la sincronización, pero el autor no quería guardar ciertos archivos en una máquina ajena. El requisito quedó así: Claude Code debía leer y modificar los archivos del Mac, las solicitudes al modelo debían salir a través de Linux y la autenticación debía permanecer en Linux.

La segunda idea, usar un proxy HTTP en el servidor, tampoco funcionó. El proxy cambia la ruta del tráfico, pero no entrega al cliente del Mac la autenticación de otra máquina. Por eso hicieron falta dos componentes distintos. CLIProxyAPI es una pasarela que recibe las solicitudes del Claude Code local y se comunica con Anthropic usando las credenciales del servidor. Tinyproxy reenvía el resto del tráfico del cliente: búsquedas web, MCP y otras solicitudes que, de otro modo, saldrían desde la dirección IP doméstica.

Cómo funciona la configuración

En el Mac, settings.json establece ANTHROPIC_BASE_URL en un puerto local y HTTP_PROXY y HTTPS_PROXY en un segundo puerto, mientras que apiKeyHelper proporciona la clave de la pasarela. Ambos puertos se reenvían al servidor mediante un único túnel SSH, y allí la pasarela y el proxy solo escuchan en 127.0.0.1. Un LaunchAgent inicia y reinicia el túnel. El propio modelo, por supuesto, calcula la respuesta en la nube de Anthropic. La pasarela, el token y la salida a la red permanecen en el servidor; los archivos, el agente y la ejecución de las herramientas locales permanecen en el Mac. Al modelo solo se envían los fragmentos de archivos seleccionados por el agente y los resultados de los comandos locales.

El autor realizó numerosas comprobaciones porque encontró obstáculos en cada paso. Verificó la IP externa a través del proxy, inspeccionó el binario de la extensión de VS Code y confirmó que las operaciones con archivos se ejecutaban en el Mac. También inició el cliente por separado con la pasarela y el proxy inaccesibles: no llegó ninguna respuesta por una ruta alternativa, solo apareció un error de conexión.

Dónde se rompió todo

El primer problema fue systemd. La importación de la autenticación en ExecStartPre no podía acceder a la variable de entorno necesaria, por lo que el servicio fallaba antes de que arrancara la pasarela. El autor ejecutó la importación por separado y el servicio pasó a leer un archivo auth ya preparado. El token debe actualizarse manualmente.

El segundo problema fue NO_PROXY. Sin una excepción para loopback, la solicitud a la pasarela local pasaba primero por Tinyproxy y nada funcionaba.

El tercer problema, y el más instructivo, fue el catálogo de modelos. El cliente solicitó el modelo auxiliar claude-haiku-5-5, que no figuraba en el catálogo de CLIProxyAPI 8.0.20, y recibió el error unknown provider for model. La solución consistió en añadir al catálogo una entrada para el modelo. El autor concluye que las versiones del cliente y de la pasarela deben fijarse y actualizarse de forma deliberada.

También existe otra limitación: después de que el equipo entre en reposo o se interrumpa la red, el túnel vuelve a conectarse, pero una solicitud al modelo que ya se haya cortado no se reanuda.

Qué conclusiones sacar y qué conviene recordar

El patrón resulta útil incluso fuera del contexto de los bloqueos. Si es necesario mantener las credenciales y la salida a la red en una máquina, pero los archivos y las herramientas en otra, funciona el esquema de un agente local, una pasarela detrás de un túnel SSH y un proxy independiente. También muestra que una pasarela de API y un proxy de red resuelven tareas diferentes y no se sustituyen entre sí.

Sin embargo, este enfoque presenta importantes salvedades. El propio autor reconoce que disponer de un VDS no invalida los requisitos de Anthropic sobre la ubicación real del usuario y que hacer coincidir los países de la tarjeta, la SIM y el servidor no garantiza nada. Además, comparte la suscripción con un amigo, lo que crea otra zona de riesgo: servicios y puertos compartidos en un mismo VDS, con varios usuarios que tienen acceso root.

El setup-token se guarda en el servidor, lo que convierte al servidor en un punto crítico. Eludir las restricciones regionales y compartir una suscripción pueden contravenir las condiciones del servicio, por lo que la cuenta podría volver a perderse. Para los equipos, esta arquitectura es más apropiada cuando cuentan con acceso legítimo y necesitan una salida centralizada, no como forma de eludir las reglas del proveedor.

El artículo de Habr termina en mitad del análisis de los matices del trabajo colaborativo, por lo que no ofrece una visión completa del acceso compartido.