Las reglas de Apache no coinciden

Las reglas opcionales de Apache pueden servir los archivos existentes de la caché de POM antes que PHP. Diagnostícalas solo después de que la generación de PHP y los aciertos de la caché de PHP funcionen correctamente.

Establece la línea base

Prueba temporalmente sin la regla directa opcional:

  1. borra la tienda relevante del sitio actual;
  2. solicita una URL pública limpia una vez;
  3. confirma que aparece el archivo HTML o JSON esperado;
  4. vuelve a solicitarla;
  5. verifica la cabecera de acierto de PHP.

Si PHP no genera ni reutiliza el archivo, la regla de Apache no es el primer problema.

Comprueba dónde está instalada la regla

La regla debe estar activa en el host virtual o en el contexto .htaccess que recibe el nombre de host probado. Confirma:

  • que Apache permite las directivas de anulación necesarias al usar .htaccess;
  • que el archivo está por debajo de la raíz de documentos efectiva;
  • que otro host virtual no está gestionando la solicitud;
  • que el bloque de la caché de POM se ejecuta antes que el bloque normal de reescritura de WordPress;
  • que la validación de sintaxis y la recarga del servidor se completaron correctamente.

Haz una copia de seguridad de la configuración antes de modificarla.

Haz coincidir la ruta generada

Compara el artefacto de caché real con la ruta construida por la regla:

  • raíz de la caché;
  • subárbol HTML o JSON progresivo pom-cache;
  • nombre de host de la solicitud;
  • subdirectorio multisitio, cuando corresponda;
  • comportamiento de la barra diagonal final;
  • segmentos de locale y archivo para JSON;
  • nombre de archivo HTML canónico index.html.

Las reglas suministradas suelen usar el nombre de servidor de la solicitud. Los alias de host, las redirecciones www, los puertos, los proxies o un nombre de host público/de origen diferente pueden, por tanto, apuntar a un directorio distinto.

Comprueba las condiciones de la solicitud

Un acierto HTML directo seguro es intencionadamente limitado. Confirma que la solicitud:

  • usa un método de lectura permitido;
  • tiene una cadena de consulta limpia;
  • no lleva una cookie de inicio de sesión de WordPress o de omisión de la aplicación;
  • se asigna a una ruta pública normal;
  • tiene un archivo legible existente.

Para JSON, confirma que la URL se asigna a la ruta JSON progresiva configurada y al artefacto .json exacto.

No relajes las comprobaciones de cookies, consultas o métodos solo para que la regla coincida. Una alternativa de PHP es más segura que una regla estática amplia.

Distingue un acierto directo

La entrega de Apache no ejecuta PHP, por lo que no añadirá:

X-POM-Cache: Served static cache from PHP; phase=early

Usa los registros de acceso del servidor, la información del manejador o un rastreo controlado para demostrar la entrega estática. Prueba el origen sin CloudFront para que un acierto de borde no oculte el resultado.

Los cambios de configuración requieren cambios en la regla copiada

La pantalla de ajustes proporciona reglas para desplegar; Apache ejecuta la copia instalada en el servidor. Desactivar un interruptor de WordPress o cambiar la ubicación de la caché no reescribe automáticamente esa copia del servidor.

Después de un cambio de ruta, host, multisitio o ruta:

  1. genera las reglas actuales;
  2. compáralas con el bloque instalado;
  3. despliega a través del proceso de configuración normal;
  4. valida la sintaxis;
  5. prueba solicitudes anónimas y con sesión iniciada;
  6. borra o retira las rutas de origen antiguas solo después de que el nuevo mapeo funcione.

Si el origen sirve correctamente pero la respuesta pública sigue obsoleta, diagnostica CloudFront sigue sirviendo contenido antiguo.