Cómo ver un sitio web en un servidor nuevo antes de cambiar los DNS: todos los métodos comparados

Un servidor suele alojar muchos sitios y elige uno por el nombre de dominio que envía el navegador, así que http://203.0.113.10/ muestra una página por defecto o un aviso de certificado. Todos los métodos de abajo envían la petición a la nueva IP diciendo «quiero example.com». Se diferencian en quién puede ver el resultado, en qué dispositivos y en lo exacto que es.

Tu sistema operativo lee el archivo hosts antes de consultar los DNS. Una línea por nombre de host apunta tu dominio al servidor nuevo, solo en este equipo:

# Windows: C:\Windows\System32\drivers\etc\hosts  (edit as Administrator)
# macOS / Linux: /etc/hosts  (edit with sudo)
203.0.113.10   example.com
203.0.113.10   www.example.com

# Then flush the DNS cache
ipconfig /flushdns                                              # Windows
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder   # macOS
resolvectl flush-caches                                         # Linux with systemd-resolved

• Ventajas: exacto, gratuito y sirve para todo: IP privadas, cualquier puerto, el certificado y las cabeceras propios del servidor nuevo. El generador de archivo hosts escribe las líneas por ti.
• Inconvenientes: un equipo cada vez, necesita permisos de administrador, poco práctico en iOS y Android, y fácil de olvidar. Una línea olvidada después de la migración te deja en el servidor equivocado.
• Ideal para: un desarrollador que revisa su propio trabajo, y la última comprobación de HTTPS, cabeceras de seguridad e inicio de sesión con terceros antes del cambio.

--resolve le dice a curl qué IP usar para un nombre de host, así que la petición lleva tu dominio real, también en el handshake TLS, y el certificado se comprueba:

# Status line and headers from the new server, over HTTPS
curl -sI --resolve example.com:443:203.0.113.10 https://example.com/

# The page title, to make sure it is your site and not a default page
curl -s --resolve example.com:443:203.0.113.10 https://example.com/ | grep -i "<title>"

# No certificate yet? -k skips verification; plain HTTP works with a Host header
curl -skI --resolve example.com:443:203.0.113.10 https://example.com/
curl -sI -H "Host: example.com" http://203.0.113.10/

Usa -H "Host: …" solo con HTTP sin cifrar: por HTTPS, curl seguiría enviando la IP en el handshake TLS y comprobaría el certificado contra ella. En Windows, escribe curl.exe, porque en Windows PowerShell 5.1 curl es un alias de Invoke-WebRequest.

• Ventajas: segundos, nada que deshacer, se puede automatizar y muestra los códigos de estado, las redirecciones y el certificado tal como los envía el servidor.
• Inconvenientes: no renderiza nada: solo HTML y cabeceras, y solo para ti.
• Ideal para: confirmar que el sitio está configurado en el servidor nuevo antes de dedicar tiempo a cualquier otra cosa, y para comprobaciones en scripts o CI.

Muchos proveedores dan a cada cuenta una dirección temporal en su propio dominio, y los servidores con cPanel pueden servir una cuenta en http://203.0.113.10/~username/ si el proveedor tiene activado mod_userdir. También puedes añadir un registro para un nombre nuevo, como staging.example.com, que apunte al servidor nuevo: añade un nombre de host sin tocar los registros en producción.

• Ventajas: una URL normal que funciona en cualquier dispositivo y se puede enviar a cualquiera, sin servicios adicionales.
• Inconvenientes: el sitio responde con otro nombre de host. WordPress y la mayoría de los CMS redirigen al dominio guardado en su configuración, que todavía apunta al servidor anterior, y los enlaces absolutos y las cookies también siguen al dominio real. Arreglarlo supone un buscar y reemplazar que tendrás que deshacer antes del lanzamiento. Muchos proveedores desactivan las URL ~user, y el HTTPS es del nombre temporal, no de tu dominio.
• Ideal para: sitios estáticos y aplicaciones con URL relativas, o la entrega que hace el propio proveedor cuando no hay otra opción.

Chrome y otros navegadores basados en Chromium aceptan un parámetro de inicio que asigna nombres de host a una IP solo durante esa sesión del navegador. Una carpeta de perfil aparte garantiza que arranque una instancia nueva con la regla:

# Windows (Command Prompt)
"C:\Program Files\Google\Chrome\Application\chrome.exe" --user-data-dir=%TEMP%\chrome-preview --host-resolver-rules="MAP example.com 203.0.113.10, MAP www.example.com 203.0.113.10"

# macOS
open -na "Google Chrome" --args --user-data-dir=/tmp/chrome-preview --host-resolver-rules="MAP example.com 203.0.113.10, MAP www.example.com 203.0.113.10"

# A resolver for your whole network (dnsmasq; also covers subdomains)
address=/example.com/203.0.113.10

La última línea es la misma idea un nivel más arriba: un resolver local como dnsmasq, o un registro DNS local en Pi-hole, responde con la nueva IP a todos los dispositivos que lo usan, incluidos los teléfonos de esa wifi, siempre que usen los DNS de la red y no su propio DNS privado. Las extensiones del navegador no pueden editar el archivo hosts; algunos servicios de vista previa ofrecen una como atajo a sus enlaces (hosts.click indica una extensión para Chrome; DNSPeek todavía no tiene ninguna).

• Ventajas: no se editan archivos del sistema, no queda nada al cerrar el navegador y la respuesta es exacta, con el dominio y el certificado reales.
• Inconvenientes: el parámetro de Chrome solo funciona en escritorio y es fácil equivocarse si Chrome ya está abierto con el mismo perfil. Un resolver necesita que alguien lo mantenga y solo ayuda a quien está en tu red.
• Ideal para: desarrolladores que quieren un comportamiento exacto sin tocar el archivo hosts, y equipos que prueban en dispositivos reales en una misma oficina.

Un servicio de vista previa te da un enlace HTTPS en su propio dominio. El servicio se conecta a la IP que introdujiste, pide tu dominio real y reescribe enlaces, redirecciones y cookies para que los visitantes no salgan de la vista previa. Es el único método de esta lista que un cliente puede usar sin ayuda.

Lo que indican los propios servicios, a octubre de 2026 (detalles en DNSPeek frente a SkipDNS, DNSPeek frente a Peek-DNS y DNSPeek frente a hosts.click):

• Ventajas: teléfonos, tabletas y clientes lo abren como cualquier enlace, no hay nada que instalar ni deshacer, y una contraseña o una fecha de expiración lo mantienen bajo control.
• Inconvenientes: hay un proxy en medio. DNSPeek, por ejemplo, elimina Strict-Transport-Security, Content-Security-Policy y X-Frame-Options y ajusta los atributos de las cookies para que la vista previa funcione en su propia dirección; el inicio de sesión con Google y las páginas de pago alojadas vuelven a tu dominio real; los firewalls del servidor nuevo pueden poner a prueba el tráfico del proxy; y solo se llega a IP públicas. Consulta lo que las vistas previas no pueden hacer.
• Ideal para: la revisión de clientes e interesados, las comprobaciones en móvil y cualquiera a quien no deberías pedirle que edite archivos del sistema.

• Desarrollador en solitario, con tu propio portátil: curl --resolve, y después el archivo hosts o el parámetro de Chrome. Aquí son sencillamente la mejor opción: exactos, gratuitos y sin terceros de por medio. Usa un enlace de vista previa solo para tu teléfono.
• Agencia con aprobación del cliente: un enlace de vista previa con contraseña. El cliente nunca toca archivos del sistema; tú te quedas con el archivo hosts para comprobar HTTPS, cabeceras e inicio de sesión, que un proxy modifica. Consulta cómo conseguir la aprobación del cliente antes del lanzamiento y DNSPeek para agencias.
• Proveedor de hosting que migra clientes: las URL temporales rompen la mayoría de los CMS, así que envía enlaces de vista previa, creados con la API o con un enlace /new?domain=…&ip=… prellenado. Si hoy necesitas un botón dentro de cPanel, SkipDNS y hosts.click indican plugins de paneles; DNSPeek todavía no los tiene. Consulta DNSPeek para proveedores de hosting.

La mayoría de las migraciones combinan una comprobación exacta para ti con un enlace para todos los demás. Más sobre esa pareja: archivo hosts o enlace de vista previa; el resto de la mudanza: la checklist de migración de sitios web.

1. 1

   Paso 1: Consigue la IP del servidor nuevo

   Tómala del correo de bienvenida o del panel de control del nuevo hosting, no de una consulta de tu dominio. Consulta Encontrar la IP de tu servidor.

2. 2

   Paso 2: Comprueba que el servidor responde para tu dominio

   Ejecuta curl -sI --resolve example.com:443:203.0.113.10 https://example.com/. Un 200 o una redirección a tu propio dominio significa que el sitio está configurado; una página por defecto, que todavía no.

3. 3

   Paso 3: Míralo tú mismo en un navegador

   Añade entradas al archivo hosts con el generador de archivo hosts o inicia Chrome con --host-resolver-rules, y recorre las páginas clave, los formularios y el área de administración.

4. 4

   Paso 4: Comparte un enlace de vista previa con quien tenga que aprobar

   Introduce el dominio y la IP en el formulario de nueva vista previa, pon una contraseña si el sitio es sensible y envía el enlace a tu cliente o a tu equipo.

5. 5

   Paso 5: Deshaz tus overrides después del cambio

   Quita las líneas del archivo hosts o cierra el perfil de Chrome, y confirma que los DNS públicos ya han cambiado con el comprobador de propagación DNS.