Arribar a un servidor mitjançant la seva IP només demostra que la xarxa i un servei web predeterminat responen. No confirma que el DNS resolgui bé ni que el servidor assigni aquell hostname al virtual host de WordPress. A més, WordPress conserva el domini canònic i pot redirigir una visita directa per IP.
Conserva la configuració de DNS i allotjament abans de modificar ambdues parts.
Defineix l’avaria amb precisió
Anota els resultats per a l’arrel i www, HTTP i HTTPS, estat, certificat i cos. Compara xarxes i resolvers diferents.
Captura:
respostes A, AAAA i CNAME
nameservers i TTL
Host i SNI sol·licitats
resposta del virtual host
domini del certificat
home i siteurl de WordPressUna URL de previsualització del panell no substitueix la prova del domini final.
Verifica el DNS autoritatiu
Confirma que el registrador delega als nameservers previstos i revisa els registres al proveïdor autoritatiu.
Un AAAA antic pot enviar els visitants amb IPv6 a un altre servidor encara que l’A sigui correcte. www també pot tenir un CNAME separat.
Elimina registres duplicats conflictius amb cura. Reduir el TTL després del canvi no esborra respostes ja emmagatzemades.
Comprova DNSSEC i memòria cau negativa
Si DNSSEC està actiu, confirma que el DS del registrador coincideix amb les claus del proveïdor. Un DS antic després de migrar nameservers pot provocar SERVFAIL als resolvers validadors.
Les respostes NXDOMAIN també es conserven durant el TTL negatiu de l’SOA. No desactivis DNSSEC sense planificar la transició de claus i delegació.
Descarta la resolució local
Revisa el fitxer hosts, VPN, DNS corporatiu, memòria cau del router i DNS segur del navegador. Una xarxa interna pot utilitzar split DNS de manera intencionada.
Registra primer la resposta i neteja després només la memòria cau rellevant. No mantinguis IPs de producció als fitxers hosts del personal: fallaran silenciosament a la migració següent.
Prova el hostname contra el servidor
Utilitza temporalment un fitxer hosts o un client que enviï tant la IP de destinació com el hostname i SNI:
curl --resolve example.com:443:203.0.113.10 https://example.com/Empra localment els valors reals autoritzats i no publiquis la IP d’origen. Aquesta prova separa DNS de la configuració web.
Revisa el virtual host
cPanel o Plesk ha d’associar el domini i els àlies al document root correcte. Apache o Nginx necessita ServerName o server_name i l’arrel corresponent.
Una pàgina predeterminada indica que la petició ha arribat però ha guanyat un altre host. Corregeix la subscripció o domini addicional abans de moure WordPress. Evita dos virtual hosts amb el mateix nom.
Valida SSL i SNI
HTTPS ha de presentar un certificat que inclogui l’arrel i www utilitzats. Un certificat predeterminat sol indicar una selecció incorrecta per SNI.
Instal·la o renova Let’s Encrypt des del panell quan el DNS ja arribi al servidor i funcioni la validació ACME. No desactivis la verificació ni utilitzis un certificat d’IP com a solució permanent.
Alinea les URLs canòniques
Comprova que home, siteurl i les constants utilitzen el domini HTTPS i la ruta previstos. Que la IP redirigeixi al domini pot ser correcte.
No substitueixis aquestes URLs per la IP: trencaries galetes, enllaços, correus i SEO. Darrere de Cloudflare, configura el reenviament HTTPS només des de fonts de confiança.
Inspecciona proxy i tallafoc
Si Cloudflare està proxificat, comprova que l’origen accepta les peticions i que el mode SSL concorda amb un certificat vàlid. Compara amb cura les proves proxificades i DNS-only.
El tallafoc pot permetre les xarxes documentades de la CDN sense quedar obert globalment. No el desactivis per obtenir una resposta puntual.
Verifica més que la portada
Prova inici de sessió, recursos, REST, mitjans, redireccions canòniques, arrel i www. Confirma el DNS des de diverses ubicacions després del TTL i elimina els overrides temporals.
La monitorització recurrent ha de comprovar DNS, certificat i virtual host pel hostname. Un ping a la IP no representa l’accés real dels visitants.