A Verdadeira Razão pela Qual Minha IA Continuava Dizendo 'Ferramenta Não Encontrada' Era DDNS

Introdução

Eu configurei vários servidores MCP no meu servidor doméstico e fiz com que Claude e ChatGPT os chamassem. Eu até fiz a IA construir o servidor em si e a unidade de monitoramento, e eu senti que estava mantendo uma operação relativamente estável.

No entanto, um dia, Claude disse:

"Essa ferramenta não pode ser encontrada."

Huh. Estava funcionando bem um momento atrás.

Quando eu reinicio a sessão, funciona novamente.

Depois de um tempo, ele diz "não consigo vê-la" novamente.

Reiniciar. Isso conserta.

"Às vezes ela desaparece" é o problema mais complicado

Esse padrão é frustrante porque isolar a causa é difícil e o progresso estagna.

• O aplicativo está ativo.
• A porta está ouvindo.
• As verificações de saúde estão passando.
• Mas do lado da IA, "a ferramenta não está registrada."

Mesmo quando olho os logs do servidor, nada está falhando. Às vezes, mesmo ao verificar os logs do lado do cliente, não há nem mesmo um vestígio de que uma tentativa de conexão foi feita.

Achando estranho, deixei passar por meses, dizendo a mim mesmo: "Está tudo bem, já que um reinício conserta isso." Falhas probabilísticas como essa são algo que os humanos podem simplesmente ignorar com um 'oh, falhou novamente' ao interagir com isso. Você apenas pressiona o botão de recarregar, e é isso.

Pingar constantemente a IA torna as flutuações aparentes

Uma vez que está registrado como um MCP para a IA, a história muda.

Toda vez que uma sessão começa, a IA vai se conectar ao servidor MCP registrado. Ela resolve o nome, realiza o handshake TLS, busca a lista de ferramentas e a adiciona ao contexto. Se qualquer passo falhar durante esse processo, o estado permanece "a ferramenta está invisível" durante toda a sessão.

Falhas probabilísticas que costumavam ser resolvidas por um humano pensando "Oh, falhou, deixa eu pressionar novamente" agora se alinham perfeitamente com os limites da sessão da IA, e a conversa começa em um estado onde a ferramenta efetivamente não existe.

E porque o lado da IA só retorna "essa ferramenta não existe", a causa permanece invisível para o humano.

Suspeitei da camada mais baixa

Eu suspeitei da "rede", "TLS" e "servidor" por ordem, e finalmente, o DNS permaneceu.

Como meu servidor doméstico não tem um IP estático, eu estava usando DDNS (dynv6.net). É o padrão para aqueles sem um IP estático. Estou usando isso há anos.

Esse DDNS estava falhando ocasionalmente em resolver nomes.

Especificamente, houve momentos em que dig retornaria NXDOMAIN ou SERVFAIL. Não tenho certeza se era um problema do lado do provedor, cache upstream ou limitação de taxa. Alguns minutos depois, se eu executasse dig novamente, funcionaria normalmente como se nada tivesse acontecido.

……Isso era?

"Um nome que funcionou há alguns minutos não funciona agora" estava definitivamente acontecendo.

E se uma sessão de IA começa no momento em que a resolução do DDNS cai, a ferramenta desaparece. Eu suspeitei que essa era provavelmente a causa.

Nunca suspeitei do DNS antes

Quando percebi isso, fiquei bastante surpreso comigo mesmo.

Até agora, eu tinha quase nenhum conceito de suspeitar do DNS. Para mim, a resolução de nomes era apenas algo que você digitava na barra de endereços do navegador para ver se conectava ou não.

Eu nem estava ciente de que existia um modo "às vezes falha".

Minha consciência não estava direcionada para a existência da camada DNS. Eu nem tinha o reconhecimento de que a resolução de nomes não é uma escolha binária de "funcionando ou quebrado", mas sim algo que "às vezes funciona e às vezes não". Ter a IA pingando isso diariamente é o que finalmente direcionou minha atenção para lá.

A opção do Cloudflare Tunnel

Foi então que encontrei o Cloudflare Tunnel.

De um servidor sem um IP estático, você estabelece uma conexão de saída permanente do seu lado para a borda do Cloudflare. Do ponto de vista do cliente, ele apenas resolve via DNS do Cloudflare e se conecta à borda. Depois disso, o túnel o leva para sua casa.

Em outras palavras, meu servidor não precisa mais expor seu nome via DDNS. O DNS do Cloudflare mantém o nome, e o Cloudflare atua como o ponto de saída.

Eu só precisava registrar meu domínio (kitepon.dev) com o NS do Cloudflare e definir rotas de túnel para cada subdomínio. Nenhum IP estático é necessário. Nenhuma configuração de redirecionamento de porta é necessária. Nenhum script de atualização de DDNS é necessário.

Duas dívidas operacionais desapareceram como um bônus

Houve dois efeitos colaterais que percebi após a migração. Ambos eram recursos bônus, mas são sutilmente eficazes.

Primeiro: fui libertado da peregrinação do /etc/hosts para contramedidas de NAT de hairpin.

Eu uso a linha de 10G da SoftBank. Isso não suporta NAT de hairpin. Se eu tentar acessar meu próprio domínio público de dentro da minha LAN doméstica, a rota para sair e voltar não pode ser estabelecida, e eu fico preso.

Minha solução anterior era contornar e atualizar /etc/hosts com o endereço interno para cada dispositivo, cada contêiner e cada instância WSL. Isso era uma sutil dívida operacional; toda vez que eu adicionava um novo dispositivo ou iniciava um novo contêiner, eu era forçado a atualizar os arquivos hosts.

Uma vez que mudei para o Cloudflare Tunnel, ele usa o mesmo caminho (via Cloudflare) se eu acessá-lo de dentro ou de fora. Eu removi todo o tratamento especial para hosts.

Segundo: Na linha da SoftBank, ocasionalmente sofri com bloqueios irregulares de entrada.

Isso foi outra coisa que havia sido uma pequena irritação por anos. Seja pela linha da SoftBank, pelo gateway doméstico ou por medidas de segurança upstream, eu não consegui identificar a causa, mas houve momentos em que o acesso de fora não se conectava.

Como o Cloudflare Tunnel é uma conexão permanente estabelecida para fora do servidor doméstico, do ponto de vista do ISP, apenas "comunicação de casa para fora" ocorre. Bloqueios acionados do lado de entrada tornaram-se estruturalmente irrelevantes.

Após a migração

As IAs pararam de dizer "não consigo ver a ferramenta."

Esta é uma observação, não uma garantia absoluta. O Cloudflare em si pode não ser perfeito também. No entanto, a instabilidade do DDNS que eu operava e a disponibilidade de borda de um CDN comercial estão em ordens de magnitude diferentes. Eu tenho que admitir isso.

E como os efeitos colaterais de editar hosts e os bloqueios do lado da SoftBank também desapareceram, os gatilhos para a IA dizer "não pode acessar" diminuíram de uma só vez.

O que eu aprendi

Ao fazer a IA pingar isso diariamente, percebi que deveria suspeitar do DNS.

Para mim, o DNS era um mecanismo para "a barra de endereços do navegador." Para o acesso humano, não me incomodava se falhasse ocasionalmente.

Mas quando você começa a lançar tarefas de longo prazo em uma IA, as flutuações que você anteriormente deixou passar se tornam criticamente impactantes. Quando você coloca algo que roda 24 horas por dia em cima da sua pilha, as mentiras nas camadas subjacentes se desnudam uma a uma.

Aconteceu que, no meu servidor doméstico, a primeira camada a se desnudear foi a camada DNS.

E o meio para corrigir essa camada desnudada estava na minha frente de graça há mais de 5 anos. O Cloudflare Tunnel se tornou gratuito em 2020. Eu apenas não tinha o gatilho para notar.

Talvez a próxima camada se desnudará. Eu escreverei sobre isso novamente quando isso acontecer.