Anoche todos los nodos proxy fallaron simultáneamente.

Tres fallos concurrentes: errores de permisos en los logs de xray en VPS que causaron el colapso del proceso, archivo de configuración local de Clash dañado, IP del nodo japonés sospechosamente bloqueada. El resultado fue—la conexión con Claude Code se cortó por completo.
Fue entonces cuando me di cuenta de una cosa: me resulta muy difícil hacer un diagnóstico "en vivo" por mí mismo.
Durante más de medio año, casi todas las decisiones técnicas las tomé dialogando con AI. Leer logs, modificar configuraciones, consultar documentación, escribir scripts, todo el proceso con AI y Claude Code. De repente, la desconexión no fue solo un problema de "incómodo", sino que realmente no sabía por dónde empezar.
Finalmente, usé la suscripción de un amigo a un proxy para ponerlo en línea temporalmente, usando Claude Code.
Arreglar mi propia infraestructura: identificar las causas raíz de los tres fallos concurrentes, corregir permisos, restaurar configuraciones desde respaldo, hacer una instantánea completa en Vultr para migrar y cambiar IP. Cuatro procesos PM2, nueve tareas programadas cron, restaurar todo el código y datos tal cual, y con un nuevo IP volver a la vida.
Después de arreglarlo, hice una cosa que ya debería haber hecho: crearme un paquete de autoayuda offline.
Ejecutar un pequeño modelo localmente, junto con un manual de emergencia (escenarios de fallos + comandos de diagnóstico + parámetros de protocolo), para que cuando se pierda la conexión, el modelo local pueda leer el manual y seguir los pasos para solucionar. Sin costo, sin necesidad de red.
Una reflexión: si dependes en exceso de AI CLI para tu trabajo diario, tu capa de acceso proxy/red es tu "línea de vida AI". También necesita un diseño de alta disponibilidad—nodos principales y de respaldo que cambien automáticamente, planes de degradación offline, manual de emergencia.
Es lo mismo que desplegar un servicio en producción, solo que esta vez el servicio que falla es tu propio cerebro.