WordPress多站点DNS故障解密：主站正常子站报错的系统性排查指南

Cuando te encuentras con esta situación en una red multisitio de WordPress: el sitio principal funciona correctamente y muestra el contenido a la perfección, mientras que los subsitios suelen dar errores.Error de DNS de origenEs como escuchar una nota discordante en una sinfonía meticulosamente compuesta. Las estadísticas revelan que aproximadamente 381 administradores de WordPress multisitio se han encontrado con al menos un caso de problemas de resolución de DNS en el que el sitio principal funciona con normalidad, mientras que los subsitios fallan, con un tiempo medio de resolución de problemas superior a 90 minutos. Detrás de este patrón de fallo asimétrico se esconde el laberinto lógico único del DNS inherente a las arquitecturas multisitio.

Capítulo uno: Infraestructura de red multisitio y aspectos específicos del DNS

WordPressUna red multisitio no es simplemente una colección de sitios web, sino un sistema de publicación distribuido meticulosamente diseñado. Comprender la arquitectura fundamental de este sistema es el primer paso para desentrañar el rompecabezas del DNS de los subsitios.

1.1 Dos modos de mapeo para redes multisitio

WordPress multisitio ofrece dos modos de infraestructura, cada uno con requisitos de DNS claramente diferentes.

Patrón de subdominioEsta es la arquitectura multisitio más utilizada. En esta configuración, cada subsitio posee un subdominio independiente, como sitio1.dominioprincipal.comysitio2.dominioprincipal.comDesde el punto de vista del DNS, esto requiere que cada subdominio se resuelva correctamente a la dirección IP del servidor. En la práctica, muchos administradores lo consiguen utilizando un registro DNS comodín, un único*.dominioprincipal.comEl registro A o el registro CNAME apuntan al servidor. Sin embargo, este enfoque conciso también introduce riesgos específicos: el problema de propagación con los registros comodín y los conflictos con los registros de subdominios específicos.

Modo subdirectorioentonces se toma un camino diferente.

Todos los subsitios comparten el mismo dominio principal, que se distingue por sus rutas, como por ejemplo: maindomain.com/sitio1ydominioprincipal.com/sitio2Este modelo simplifica la configuración del DNS, ya que solo requiere que el dominio principal se resuelva correctamente. Sin embargo, introduce otra capa de complejidad: la precisión de las reglas de reescritura del servidor. Una configuración incorrecta.htaccessLas reglas de reescritura de Nginx pueden impedir que determinadas rutas de subdirectorios se enruten correctamente.

1.2 Estructura de bases de datos y archivos multisitio

La magia fundamental de una red multisitio reside en cómo gestiona múltiples sitios independientes dentro de una única instalación de WordPress. A nivel de base de datos, todos los sitios comparten un conjunto de tablas principales, mientras que cada sitio posee su propio conjunto de tablas, que se distinguen por los prefijos de las tablas. A nivel de archivos, los archivos cargados se organizan dentro de una estructura de directorios específica según el ID del sitio.

Esta estructura es adecuada paraResolución DNSEsto tiene un impacto indirecto pero significativo. Cuando una solicitud llega al servidor, WordPress debe determinar primero a qué sitio pertenece la solicitud antes de cargar la configuración y el contenido correspondientes. Este proceso de toma de decisiones se basa en el nombre de dominio o la ruta de la solicitud. Si la resolución del DNS encuentra problemas, esta cadena de decisiones puede romperse en el primer paso.

Capítulo 2: Causas únicas de errores de DNS de origen en entornos multisitio

En entornos con múltiples sitios, los errores de DNS de Origin rara vez son problemas aislados de registros DNS. En la mayoría de los casos, son el resultado de interacciones complejas entre varios componentes del sistema.

2.1 Inconvenientes de los registros DNS comodín

Los registros DNS comodín son la base de las configuraciones de subdominios multisitio, pero también suelen causar problemas.

Problemas de inconsistencia en la comunicaciónEspecialmente destacado. Al modificar registros comodín, los servidores DNS ubicados en diferentes ubicaciones geográficas pueden actualizarse a diferentes velocidades. El resultado puede ser: el nombre de dominio principaldominioprincipal.comResuelto a una nueva dirección IP, mientras que el comodín*.dominioprincipal.comSigue apuntando a la IP antigua. Este estado dividido hace que el sitio principal funcione con normalidad, mientras que el subsitio falla debido a que se resuelve en una IP no válida.

Conflictos de prioridad en la talaEs otro escollo. Si existen simultáneamente registros comodín y registros explícitos para subdominios específicos, el resolutor DNS debe determinar cuál utilizar. La mayoría de los sistemas se adhieren al principio de «la coincidencia más específica», lo que significa quesitio1.dominioprincipal.comLos registros explícitos prevalecerán sobre los demás.*.dominioprincipal.comRegistros comodín. Cuando se configuran explícitamente de forma incorrecta, solo afectan a ese subdominio específico, lo que explica perfectamente por qué el fallo es selectivo.

// Lógica central de WordPress multisitio que intenta identificar sitios basándose en nombres de dominio
$current_blog = get_blog_details(['domain' => $_SERVER['HTTP_HOST']]); if (!$current_blog) {     // Si el dominio no coincide con ningún sitio registrado, se puede activar un error.     wp_die('El sitio no existe o la resolución DNS es defectuosa'); }

2.2 Configuración de WordPress y desconexión de DNS

wp-config.phpLas configuraciones multisitio deben estar alineadas con precisión con los ajustes DNS; de lo contrario, se producirán fallos sutiles y persistentes.

Constante DOMAIN_CURRENT_SITEDefine el nombre de dominio principal de la red. Si este valor no coincide con el nombre de dominio real al que se accede, es posible que WordPress no pueda inicializar correctamente el entorno multisitio. Considere este escenario: el registro DNS seráwww.maindomain.comApunta al servidor, pero DOMAIN_CURRENT_SITE está configurado endominioprincipal.com(sin el prefijo www). Esta discrepancia puede provocar que algunas solicitudes se gestionen de forma anómala.

SUNRISE ConstanteGestiona las asignaciones de nombres de dominio en entornos multisitio. Si la función sunrise está habilitada, pero la tabla de asignación de dominios correspondiente (wp_mapeo_de_dominios) que contengan registros erróneos u obsoletos, las solicitudes de dominios específicos pueden desviarse o incluso perderse por completo.

2.3 Problemas jerárquicos en la configuración del servidor

El software del servidor debe interpretar correctamente las estructuras multisitio para dirigir las solicitudes a la ruta de procesamiento adecuada.

Reglas de reescritura .htaccess de ApacheEsto es especialmente importante en el modo de subdirectorios multisitio. Las reglas predeterminadas de WordPress multisitio están diseñadas para reescribir las solicitudes de subdirectorios al archivo de índice correcto. Sin embargo, si estas reglas se modifican, se corrompen o están incompletas, es posible que las solicitudes de subdirectorios específicos no lleguen al controlador front-end de WordPress. En su lugar, pueden procesarse como solicitudes de archivos estáticos o devolver directamente un error 404.

Configuración de NginxSe requiere un ajuste similar. Los entornos con múltiples sitios suelen requerir complejosnombre_del_servidorEmparejamiento yreescribirUn error común es incluir solo el dominio principal en la configuración, olvidando el nombre de servidor comodín necesario para los patrones de subdominio.

Capítulo tres: Diagnóstico sistemático: de los síntomas a las causas fundamentales

Cuando se enfrenta a un fallo en el que el sitio principal funciona con normalidad mientras que el subsitio presenta anomalías, es necesario adoptar un enfoque de diagnóstico sistemático para eliminar de forma metódica las posibilidades una por una.

3.1 Fase uno: autenticación a nivel de DNS

En primer lugar, confirme si el problema existe realmente a nivel del DNS.

Realizar consultas DNS jerárquicasCrucial. Utilizar.digLos comandos comprueban la resolución del dominio principal y del subdominio defectuoso, respectivamente:

dig maindomain.com A dig subdomain.maindomain.com A dig *.maindomain.com A

Compare los resultados de estas consultas. Lo ideal es que el dominio principal y los registros comodín apunten a la misma dirección IP. Si se encuentra alguna discrepancia, esto constituye una prueba directa del problema.

Verifique la coherencia de los tipos de registros DNS.Asegúrese de que todos los registros relevantes utilicen el mismo tipo de registro (normalmente un registro A o un registro CNAME). Los tipos de registros mixtos pueden dar lugar a un comportamiento de resolución impredecible.

Verificar la configuración del valor TTLLos valores TTL excesivamente altos (como 86 400 segundos/24 horas) pueden prolongar significativamente el tiempo de propagación de los cambios en el DNS. Si los registros DNS se han modificado recientemente, los valores TTL elevados pueden explicar por qué algunos usuarios siguen teniendo problemas.

3.2 Fase dos: Auditoría de configuración de WordPress

Después de confirmar que el DNS funciona correctamente, proceda a la configuración interna de WordPress.

Revisar la configuración clave en wp-config.php::

define('MULTISITE', true); define('SUBDOMAIN_INSTALL', true); // O false, debe coincidir con la arquitectura real define('DOMAIN_CURRENT_SITE', 'maindomain.com'); define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1); define('BLOG_ID_CURRENT_SITE', 1);

Cada definición debe reflejar con precisión la estructura real de la red.

Comprueba la tabla de mapeo del sitio.Si utiliza un complemento de asignación de dominios, consulte la tabla de asignación en la base de datos:

SELECT * FROM wp_domain_mapping WHERE dominio LIKE '%subdomain%';

Asegúrese de que la relación de asignación existe y es correcta, yactivoEl valor del campo es 1.

Verificar el estado de registro del sitio.En el panel de administración de la red de WordPress, comprueba que el subsitio afectado existe y está configurado como «Público». Los sitios que se han archivado o marcado como spam de forma involuntaria pueden mostrar un comportamiento similar a los errores de DNS.

3.3 Fase tres: Pruebas del entorno del servidor

Finalmente, descartamos los problemas a nivel del servidor.

Prueba de acceso HTTP sin procesarOmita WordPress y pruebe directamente la respuesta del servidor a una URL específica:

curl -I http://subdomain.maindomain.com curl -I http://maindomain.com/subsite-path

Observe el código de estado devuelto. Un 200 indica una respuesta satisfactoria del servidor, mientras que un 404 o un 500 sugiere un problema de configuración del servidor.

Revisar los registros del servidor.Apache(utilizado como expresión nominal)error_logo Nginx'serror.logPuede contener información detallada sobre solicitudes erróneas. Localice las entradas relacionadas con el subdominio defectuoso, prestando especial atención a las denegaciones de permiso, las reglas de reescritura fallidas o los errores de tiempo de espera.

Comprueba los permisos y la propiedad del archivo.En redes con múltiples sitios, los directorios de carga en diferentes sitios requieren una configuración correcta de los permisos. Aunque esto no suele causar errores de DNS, puede producir síntomas similares de «recurso no encontrado».

Capítulo cuatro: Plan de remediación específico

Basándose en los resultados del diagnóstico, aplique medidas correctivas precisas.

4.1 Resolución de problemas de DNS con comodines

Si el diagnóstico apunta a un problema de DNS comodín:

Implementar registros de subdominio explícitos como solución temporal.Mientras se espera la propagación del registro comodín, cree registros A explícitos para los subdominios afectados. Esto proporciona una mitigación inmediata al tiempo que permite que el registro comodín continúe propagándose.

Ajuste el valor TTL a un nivel razonable.Antes de implementar los cambios en el DNS, reduzca temporalmente el valor de TTL a 300 segundos (5 minutos). Una vez completados los cambios, el TTL puede aumentarse a un valor estable según sea necesario, como por ejemplo 3600 segundos (1 hora).

Verificación de la coherencia entre múltiples proveedores de DNSSi se utilizan varios proveedores de DNS (como un proveedor principal y un proveedor secundario), asegúrese de que los registros sean coherentes en todos los proveedores. Las discrepancias pueden provocar fallos intermitentes.

4.2 Corrección de errores de configuración de WordPress

En cuanto a los problemas a nivel de configuración:

Implementar scripts de validación de configuración.Cree un pequeño script PHP para verificar la coherencia de la configuración multisitio:

$expected_domain = 'maindomain.com'; $actual_domain = $_SERVER['HTTP_HOST']; $network_domain = defined('DOMAIN_CURRENT_SITE') ? DOMAIN_CURRENT_SITE : '';

if (network_domain && actual_domain !== expected_domain) {     // Registrar discrepancia en la configuración     error_log("Discrepancia en el dominio: Se esperaba {expected_domain}, se obtuvo {actual_domain}"); }

Reglas de reescrituraEn ocasiones, las reglas de reescritura de WordPress pueden corromperse. Basta con guardar la configuración en «Ajustes» -> «Enlaces permanentes» en el área de administración de la red multisitio para que se vuelvan a generar las reglas.

Evaluación del impacto del complemento en las actividades de revisiónDesactive uno por uno los plugins que puedan afectar al enrutamiento de URL o a la funcionalidad multisitio, en particular los plugins de almacenamiento en caché, los plugins de seguridad y los plugins de integración CDN. Estos plugins a veces gestionan las solicitudes de subdominios o subdirectorios de formas específicas.

4.3 Optimización de la configuración del servidor

Asegúrese de que el software del servidor sea compatible con una arquitectura multisitio.

Configuración optimizada para Apache::

RewriteEngine On RewriteBase / RewriteRule ^index\.php$ - [L] # Regla básica para subdirectorios multisitio RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^ - [L] RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L] Regla de reescritura ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L] Regla de reescritura . index.php [L]

Configuración precisa para Nginx::

servidor {   nombre_servidor maindomain.com *.maindomain.com;   # Subdirectory Rewrite   ubicación ~ ^/[_0-9a-zA-Z-]+/ {     try_files $uri $uri/ /index.php?$args;   }
    
    # Manejo estándar de WordPress ubicación / {     try_files $uri $uri/ /index.php?$args; } }

Capítulo cinco: Estrategias preventivas y mantenimiento a largo plazo

Prevenir los problemas de DNS en múltiples sitios es más eficaz que solucionarlos.

5.1 Establecimiento de prácticas de configuración como código

Incorporar configuraciones clave en el sistema de control de versiones.wp-config.phpLos componentes multisitio, las reglas de reescritura del servidor e incluso los archivos de zona DNS (cuando sean compatibles) deben almacenarse bajo control de versiones. Esto garantiza que los cambios sean rastreables y que sea posible revertirlos.

5.2 Implementación de supervisión y alarmas

Configure la supervisión de métricas clave en redes con múltiples sitios:

Supervisión de la resolución DNSInspeccione periódicamente los resultados de resolución del dominio principal y los subdominios representativos desde múltiples ubicaciones globales. Alerte inmediatamente al detectar inconsistencias.

Comprobación de accesibilidad del sitio webAcceda regularmente a las páginas clave de cada subsitio mediante scripts automatizados para verificar que se devuelven los códigos de estado HTTP y el contenido correctos.

Verificación de la coherencia de la configuraciónImplementa scripts de verificación para que se ejecuten periódicamente, comprobando la coherencia entre las configuraciones de WordPress, las asignaciones de bases de datos y los patrones de acceso reales.

5.3 Establecer un proceso de gestión del cambio

Cualquier cambio que pueda afectar al DNS multisitio debe seguir un procedimiento estricto:

Pruebas previas al cambioVerifique el efecto de las modificaciones del DNS en un entorno que no sea de producción.
aplicación por fasesImpleméntelo inicialmente en un pequeño número de subsitios no críticos, observe los resultados y, a continuación, implántelo de forma generalizada.
Monitorización del periodo de transmisiónSupervise de cerca la accesibilidad de todos los sitios durante la propagación del DNS.
Plan de contingencia para la reversiónSiempre hay que tener procedimientos de reversión claros en caso de que los cambios causen problemas inesperados.

Los errores de DNS de origen en redes multisitio rara vez son incidentes aleatorios. Por lo general, se manifiestan como una falta de coordinación o una configuración incorrecta en algún nivel del sistema. Al comprender las particularidades de las arquitecturas multisitio, adoptar enfoques de diagnóstico sistemáticos, implementar medidas correctivas precisas y establecer prácticas de mantenimiento preventivo, los administradores pueden reducir significativamente tanto la frecuencia como el impacto de tales fallos.En última instancia, una red multisitio saludable debe ser transparente: ni los usuarios ni los administradores del sitio deben preocuparse por las complejidades subyacentes del DNS. Este es precisamente el objetivo que deben esforzarse por alcanzar los diseñadores y mantenedores de sistemas.

Contacte con nosotros
¿No puede leer el tutorial? Póngase en contacto con nosotros para obtener una respuesta gratuita. Ayuda gratuita para sitios personales y de pequeñas empresas	Servicio de atención al cliente WeChat
① Tel: 020-2206-9892
② QQ咨询：1025174874
(iii) Correo electrónico: [email protected]
④ Horario de trabajo: de lunes a viernes, de 9:30 a 18:30, días festivos libres