Como testar site em novo IP sem alterar DNS usando curl --resolve com validação completa

Em migração de servidor, o erro clássico é testar por IP e concluir que “está ok”, sem validar virtual host, TLS e redirects reais de domínio. O comando curl --resolve resolve esse problema ao simular mapeamento DNS temporário por requisição, sem tocar no DNS público.

Por que testar por IP puro é insuficiente

Se você roda:

curl https://NOVO_IP

pode receber:

• vhost default (site errado);
• certificado incorreto;
• redirect inconsistente.

Isso não valida comportamento real do domínio.

Uso correto do --resolve

curl -skI --resolve meudominio.com:443:148.113.xxx.xxx https://meudominio.com

Esse formato injeta resolução local para aquela chamada:

• host: meudominio.com
• porta: 443
• IP alvo: novo servidor

Testes mínimos que executo antes do cutover

1. status da home:

curl -sk -o /dev/null -w "%{http_code}\n" --resolve meudominio.com:443:148.113.xxx.xxx https://meudominio.com/

1. login/admin:

curl -skI --resolve meudominio.com:443:148.113.xxx.xxx https://meudominio.com/wp-admin

1. endpoint de API:

curl -skI --resolve meudominio.com:443:148.113.xxx.xxx https://meudominio.com/api/health

1. cadeia de redirecionamento:

curl -skL --resolve meudominio.com:443:148.113.xxx.xxx -o /dev/null -w "final=%{url_effective} code=%{http_code}\n" https://meudominio.com

Script de automação simples

#!/usr/bin/env bash
set -euo pipefail

DOMAIN="meudominio.com"
NEW_IP="148.113.xxx.xxx"
PATHS=("/" "/wp-admin" "/api/health")

for p in "${PATHS[@]}"; do
  code=$(curl -sk -o /dev/null -w "%{http_code}" --resolve "${DOMAIN}:443:${NEW_IP}" "https://${DOMAIN}${p}")
  printf '%-20s -> %s\n' "$p" "$code"
done

Validação TLS além do status HTTP

Se o ambiente já tem certificado válido no novo host, teste sem -k:

curl -sI --resolve meudominio.com:443:148.113.xxx.xxx https://meudominio.com

Se falhar, diagnostique cadeia de certificado antes da virada DNS.

Boas práticas de cutover

1. reduzir TTL DNS antes da janela;
2. validar endpoints críticos com --resolve;
3. manter rollback pronto para IP antigo;
4. monitorar 5xx e latência após troca.

Erros comuns que já vi no pré-cutover

Teste passa em HTTP e falha em HTTPS

Causa: certificado ausente ou cadeia incompleta no novo host.

Home responde 200, mas app quebra

Causa: só endpoint raiz foi testado; rotas com autenticação/API ficaram fora.

Redirect loop no novo servidor

Causa: regra de rewrite dependente de header/proxy não replicada no destino.

Por isso sempre testo múltiplas rotas e cadeia de redirecionamento antes de\nalterar DNS público.

Conclusão

curl --resolve é o método mais confiável para homologar novo host sem impactar usuários. Ele valida o cenário real de domínio/HTTPS antes do cutover público, reduzindo risco de downtime e rollback emergencial.

Este post está licenciado sob CC BY-NC.