昨晚所有代理节点同时炸了。

três falhas simultâneas: erro de permissão nos logs do xray no VPS causando crash do processo, arquivo de configuração local do Clash corrompido, IP do nó japonês suspeito de estar bloqueado. O resultado foi — a conexão com Claude Code foi completamente interrompida.
Foi aí que percebi uma coisa: é muito difícil para mim fazer uma investigação "nua e crua".
Nos últimos seis meses, quase todas as decisões técnicas foram tomadas através de diálogo com IA. Ler logs, alterar configurações, consultar documentação, escrever scripts, tudo com IA e Claude Code. De repente, a conexão caiu, e não foi nem uma questão de "desconforto", mas sim de não saber por onde começar.
No final, consegui colocar no ar temporariamente usando a assinatura de um amigo com um proxy, usando Claude Code.
Corrigi minha infraestrutura: identifiquei as causas raízes das três falhas simultâneas, corrigi permissões, recuperei configurações a partir de backups, e fiz uma migração de IP com snapshot completo na Vultr. Quatro processos PM2, nove tarefas agendadas no cron, todo o código e dados restaurados exatamente como estavam, e com um novo IP, recuperei totalmente.
Depois de consertar, fiz uma coisa que já devia ter feito há muito tempo: criei um pacote de autoajuda offline.
Executei um pequeno modelo localmente, junto com um manual de emergência (cenários de falha + comandos de diagnóstico + parâmetros de protocolo), assim quando ficar sem conexão, o modelo local pode seguir o manual passo a passo para investigar. Sem custo, sem precisar de internet.
Uma reflexão: se você depende intensamente de IA CLI no seu trabalho diário, sua camada de acesso proxy/rede é sua "linha de vida IA". Ela também precisa de um design de alta disponibilidade — troca automática entre nós primário e de backup, planos de fallback offline, manual de emergência.
Assim como na implantação de serviços de produção, só que desta vez o serviço que caiu foi seu próprio cérebro.