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 domain.com:443:148.113.xxx.xxx https://domain.com

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

• host: domain.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 domain.com:443:148.113.xxx.xxx https://domain.com/

1. login/admin:

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

1. endpoint de API:

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

1. cadeia de redirecionamento:

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

Script de automação simples#

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

DOMAIN="domain.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 domain.com:443:148.113.xxx.xxx https://domain.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.

Considerações práticas#

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.

Veja também

Infraestrutura Como criar um proxy inteligente para comparar servidores durante a migração

Infraestrutura Sobrevivendo ao kernel panic: diagnosticando e contornando regressões no boot do CachyOS com Limine

Infraestrutura Gmail rejeitando e-mails do DirectAdmin: como autenticar o hostname com SPF e DKIM

Este post está licenciado sob CC BY-NC.