Siga uma requisição do DNS ao seu aplicativo.

Anote a rota que você espera

Este passo a passo assume uma VPS Linux que você administra, uma sessão SSH funcional, um aplicativo com um endpoint inofensivo /healthz e acesso às configurações autoritativas de DNS de um domínio que você controla. O aplicativo de exemplo escuta em 127.0.0.1:3000; Caddy é o proxy reverso público. Se seu aplicativo usa um supervisor ou proxy diferente, mantenha a ordem de diagnóstico e use a documentação dele.

api.example.com e 203.0.113.10 são espaços reservados de documentação, não um serviço ativo. Substitua ambos antes de executar verificações no seu próprio sistema. Anote o hostname real, o endereço IP pretendido, a porta do aplicativo e o nome do serviço em um único lugar. Definir um hostname de VPS no configurador não cria um registro DNS público.

1. O DNS retorna o endereço pretendido.
2. A conexão alcança o servidor e a porta pretendidos.
3. O TLS autentica o hostname solicitado.
4. O proxy encaminha a requisição para o upstream correto.
5. O aplicativo retorna a resposta esperada.

Verifique ambas as famílias de endereços

De uma máquina fora da VPS, consulte os registros que você pretende publicar. dig pertence às ferramentas DNS do BIND; os nomes dos pacotes variam. Esses comandos solicitam a seção de resposta para que você veja o tipo de registro, endereço e tempo de vida restante no cache. Veja a referência do BIND dig.

dig api.example.com A +noall +answer
dig api.example.com AAAA +noall +answer

Compare cada endereço retornado com seu destino pretendido. Publique um registro AAAA apenas quando o roteamento, a escuta e a filtragem de IPv6 funcionarem para esse endereço. Um registro AAAA antigo pode enviar alguns clientes para um lugar diferente do registro A. Se você usa intencionalmente um CDN ou proxy DNS, os endereços dele podem estar corretos; registre esse salto adicional em vez de assumir que a VPS deve aparecer.

Uma resposta em branco precisa de um olhar mais atento à dig resposta completa: pode significar nenhum registro desse tipo, um nome inexistente ou um problema de resolução. Verifique qual serviço DNS é autoritativo antes de editar. Registre o valor antigo e o TTL, faça a mudança pretendida lá, depois compare resultados novos após os caches existentes expirarem. Edições repetidas e não relacionadas tornam a linha do tempo mais difícil de entender.

Separe falhas de conexão de falhas de certificado

Solicite o pequeno endpoint de fora do servidor. Use GET em vez de assumir que seu aplicativo implementa HEAD. As opções de timeout do Curl limitam a verificação; sua saída verbose mostra o progresso de conexão e TLS. O Curl documenta essas opções e a verificação de certificado.

curl --verbose --connect-timeout 5 --max-time 10 https://api.example.com/healthz

Um erro de resolução aponta de volta para o DNS. Uma conexão recusada significa que a conexão foi ativamente rejeitada; um timeout pode envolver roteamento ou filtragem e não identifica qual firewall causou isso. Um erro de certificado significa que a conexão segura esperada não foi estabelecida. Não faça da desativação das verificações de certificado sua correção permanente.

Para comparar uma origem específica mantendo o hostname na requisição TLS, use a substituição de endereço do curl:

curl --verbose --connect-timeout 5 --max-time 10 --resolve api.example.com:443:203.0.113.10 https://api.example.com/healthz

Se isso funcionar enquanto a solicitação comum falhar, compare o DNS e qualquer intermediário. Esta substituição não edita o DNS. Quando registros A e AAAA existirem, repita a solicitação comum com --ipv4 e --ipv6 de um cliente que realmente suporte a rede correspondente.

Inspecione a extremidade do servidor da conexão

No VPS, inspecione os sockets TCP em escuta e consulte o aplicativo diretamente:

sudo ss -ltnp
curl --silent --show-error --max-time 5 http://127.0.0.1:3000/healthz

ss mostra os listeners e, com permissões suficientes, seus processos. Um listener em loopback é acessível localmente; sua presença por si só não diz nada sobre acesso externo. Consulte o manual do ss upstream. Se a solicitação direta ao aplicativo falhar, passe para o guia de diagnóstico de processos antes de alterar o DNS.

Para este layout de aplicativo único, o bloco relevante do Caddyfile é:

api.example.com {
    reverse_proxy 127.0.0.1:3000
}

O nome do host e o upstream devem corresponder ao seu aplicativo. A diretiva reverse proxy do Caddy encaminha solicitações para o upstream configurado; colocar um domínio arbitrário aqui não lhe dá controle sobre ele. Preserve a configuração existente antes de editar. Com o serviço empacotado e este caminho de arquivo, valide primeiro e só recarregue após a validação bem-sucedida:

sudo caddy validate --config /etc/caddy/Caddyfile --adapter caddyfile
sudo systemctl reload caddy

Os comandos têm propósitos diferentes: a validação verifica o carregamento da configuração, enquanto o reload aplica a alteração. Verifique o caminho real do arquivo e as permissões do serviço instalado. A referência de comandos do Caddy explica o comportamento de validação e reload.

Verifique o caminho completo e, em seguida, mantenha as evidências

Para automação comum de certificados públicos, o Caddy precisa de DNS correto, portas de desafio acessíveis externamente, permissão para vincular seus listeners e armazenamento de certificados gravável e persistente. Os desafios HTTP e TLS-ALPN usam as portas 80 e 443 respectivamente; um desafio DNS é uma configuração separada. Veja os pré-requisitos do HTTPS do Caddy. Mantenha o acesso administrativo intacto ao revisar regras de firewall.

Resultado ilustrativo: o endpoint local retorna {"status":"ok"}, a solicitação externa HTTPS retorna o mesmo corpo pequeno, e o curl reporta verificação de certificado bem-sucedida. Estas são observações esperadas para este exemplo, não resultados registrados de um servidor OffVPS. Exercite também uma ação normal do aplicativo: um endpoint de health superficial pode passar enquanto uma rota dependente de banco de dados falha.

Registre o horário da solicitação, o nome do host, a família de endereços e a primeira camada com falha. Esse resumo é mais útil do que “o domínio está quebrado”. Quando o caminho funcionar, use o guia de release repetível para tornar as mesmas verificações parte de cada implantação.