Si necesitás limpiar la caché de NGINX, primero confirmá que el hosting realmente utiliza NGINX y que su caché está activa. NGINX puede funcionar solamente como servidor web o proxy inverso, sin almacenar copias de las páginas. También puede haber otras capas de caché en WordPress, el navegador o una CDN como Cloudflare.
Vaciar todas las capas al mismo tiempo puede ocultar el origen del problema. Para diagnosticar correctamente, conviene purgar una por vez y comprobar el resultado en una ventana privada del navegador.
Cuándo puede ser necesario limpiar la caché
Los síntomas habituales son una página que continúa mostrando textos antiguos, estilos que no cambian, imágenes reemplazadas que siguen apareciendo o una redirección que conserva el destino anterior. Sin embargo, esos síntomas no demuestran por sí solos que NGINX sea el responsable.
Antes de purgar, verificá que el cambio haya sido guardado en WordPress o que el archivo nuevo esté realmente en el servidor. Si la modificación no llegó al origen, limpiar la caché no la hará aparecer.
Qué capas de caché pueden intervenir
- Navegador: conserva archivos en el dispositivo del visitante.
- Plugin de WordPress: puede generar páginas HTML o archivos optimizados.
- Aplicación: WordPress, un tema o un plugin pueden mantener objetos y datos temporales.
- NGINX o proxy del servidor: puede guardar respuestas generadas por Apache o PHP.
- CDN: Cloudflare u otro servicio puede entregar una copia desde su propia red.
- Caché de objetos: Redis o Memcached pueden conservar resultados de consultas, aunque no suelen almacenar la página completa.
Cada capa tiene una función diferente. Para comprender la del servidor, revisá primero qué es NGINX y cómo funciona como proxy.
Primer paso: comprobar el sitio sin la caché del navegador
Abrí la página en una ventana privada o desde otro navegador y realizá una recarga completa. También podés agregar temporalmente un parámetro a una imagen o archivo estático, por ejemplo ?v=2, para comprobar si el navegador solicita una URL diferente.
Esta prueba no garantiza que las demás capas se omitan, pero permite descartar una copia local. Evitá usar solamente la sesión de administrador de WordPress como referencia, porque algunos sistemas excluyen a los usuarios conectados y muestran una respuesta distinta a la de los visitantes.
Segundo paso: vaciar el plugin de caché
Si WordPress utiliza un plugin de caché, ejecutá su opción de vaciado o purge desde el panel. Cuando también optimiza CSS o JavaScript, puede ofrecer una limpieza separada para esos archivos. Después, revisá el sitio en una ventana privada.
No elimines manualmente carpetas del plugin si existe una opción oficial. El propio plugin conoce qué archivos, reglas y datos temporales debe regenerar.
Tercer paso: buscar una opción de NGINX en el panel
Algunos proveedores incorporan en cPanel una herramienta para administrar o purgar la caché del servidor. Si está disponible, utilizá esa opción. La interfaz y el nombre pueden variar según la implementación.
En cPanel con NGINX como proxy inverso, la caché es administrada por el servidor y sus archivos se almacenan con permisos restringidos. Por ese motivo, un usuario de hosting compartido no debería intentar borrarlos desde File Manager, FTP o un script PHP.
Si no aparece una herramienta, consultá con soporte e indicá la URL exacta afectada. Que NGINX figure en una cabecera no confirma que la caché esté habilitada ni que el usuario pueda purgarla directamente.
Cuarto paso: limpiar la caché de Cloudflare
Si el dominio utiliza Cloudflare, la respuesta desactualizada puede estar en su red. Cuando el cambio afecta una sola página o archivo, es preferible purgar la URL concreta. El vaciado completo queda reservado para modificaciones amplias porque obliga a reconstruir toda la caché y puede aumentar temporalmente las solicitudes al servidor.
También podés revisar la guía sobre cómo funciona Cloudflare. Recordá que purgar Cloudflare no elimina la copia de un plugin ni la de NGINX.
Cómo reconocer qué capa respondió
Las herramientas de desarrollo del navegador permiten revisar las cabeceras HTTP. Dependiendo de la configuración pueden aparecer indicadores de caché, edad de la respuesta o información de Cloudflare. Un valor de HIT suele indicar que una capa entregó una copia; MISS significa que no encontró una copia válida en esa solicitud.
Estas cabeceras son pistas, no una prueba universal. El administrador puede ocultarlas, cambiarlas o utilizar nombres personalizados. Además, una respuesta podría ser MISS en Cloudflare y, al mismo tiempo, HIT en el proxy del servidor.
Contenido dinámico que no debería quedar almacenado
Carritos, procesos de pago, áreas privadas, paneles de administración y páginas personalizadas normalmente requieren exclusiones. Si un visitante recibe información perteneciente a otra sesión, cerrá temporalmente la función de caché afectada y contactá al soporte de inmediato.
En WordPress también suelen excluirse las cookies de usuarios conectados y las rutas administrativas. Las reglas exactas dependen del sitio y no conviene copiarlas sin revisar el funcionamiento de la aplicación.
Qué no conviene hacer
- No elimines directorios del sistema ni cambies sus permisos.
- No ejecutes scripts encontrados en Internet para borrar archivos fuera de tu cuenta.
- No reinicies servicios en un servidor de producción sin identificar el problema.
- No desactives permanentemente toda la caché como primera medida.
- No supongas que un contenido antiguo siempre proviene de NGINX.
En un VPS con acceso root, la purga puede administrarse mediante la configuración y las herramientas del servidor, pero debe respetar la ubicación real de la caché y las políticas del servicio. Un comando incorrecto puede afectar a varios sitios.
Orden recomendado para diagnosticar
- Confirmá que el cambio exista en WordPress o en los archivos del hosting.
- Probá desde una ventana privada.
- Vaciá la caché del plugin y los archivos optimizados.
- Purgá la URL en Cloudflare si el dominio utiliza esa CDN.
- Usá la herramienta de NGINX del panel, si está disponible.
- Revisá cabeceras y compará la respuesta pública con la sesión administradora.
- Si el problema continúa, enviá al soporte la URL, la hora de la prueba y una descripción del cambio esperado.
Cuándo esperar en lugar de purgar
Algunos cambios no dependen de una caché web. La propagación DNS, la renovación de certificados o una actualización externa pueden requerir tiempo. Limpiar NGINX repetidamente no acelera esos procesos.
Conclusión
La forma segura de limpiar una caché es identificarla antes de actuar. En hosting compartido, utilizá las opciones del plugin, del panel y de la CDN; no borres carpetas del servidor. Si no podés determinar qué capa conserva la copia, el soporte puede revisar la URL y confirmar si NGINX está almacenando la respuesta.
