Proteger wp-admin con autenticación básica en Nginx

📅 Publicado el 30 de octubre, 2026 · Por Equipo RedServicio

Bloquear el acceso a wp-admin en Nginx es de esas medidas que cuestan poco y dan mucho. La zona de administración de WordPress es, con diferencia, lo primero que ataca cualquier bot: miles de peticiones diarias contra el formulario de login, probando combinaciones de usuario y contraseña a lo bruto. Si pones una segunda puerta de autenticación a nivel de servidor, la petición ni siquiera llega a PHP. La inmensa mayoría de esos ataques se quedan fuera de forma automática, y el coste en rendimiento es casi nulo.

¿Por qué proteger wp-admin con autenticación básica en Nginx?

WordPress alimenta una parte enorme de la web, y eso lo convierte en blanco permanente. El directorio /wp-admin y el archivo wp-login.php los escanean sin descanso en cualquier sitio con tráfico medio. Los bots van a lo que van: usuarios y contraseñas débiles. Los plugins de seguridad ayudan, sí, pero actúan cuando la petición ya está dentro de WordPress, gastando recursos de PHP y de la base de datos.

La autenticación básica de Nginx va por otro camino: el propio servidor rechaza la petición antes de ejecutar una sola línea de código de WordPress. ¿Qué ganas con esto?

• Rendimiento: los bots sin credenciales reciben un 401 y fuera. Procesar un login fallido en PHP pesa muchísimo más.
• Defensa en profundidad: aunque alguien acierte tu contraseña de WordPress, aún le falta la de servidor. Dos cerraduras, no una.
• Independencia de WordPress: si un plugin de seguridad se desactiva o falla, esta capa sigue ahí.

Eso sí, un detalle que conviene no pasar por alto: la autenticación básica transmite las credenciales codificadas en Base64, no cifradas. Sin HTTPS con certificado SSL válido, no intentes nada. Antes, arregla eso.

Requisitos previos antes de empezar

Antes de ponernos manos a la obra, revisa que cumples esto:

1. Acceso root o sudo al servidor donde corre Nginx, ya sea un VPS, un servidor dedicado o un entorno gestionado donde puedas editar la configuración.
2. Nginx instalado y funcionando. Puedes comprobarlo con nginx -v y revisando que el servicio esté activo con systemctl status nginx.
3. Saber dónde está tu bloque server de Nginx, normalmente en /etc/nginx/sites-available/ o /etc/nginx/conf.d/.
4. HTTPS activo en el dominio, para que las credenciales viajen cifradas.
5. Un acceso alternativo (SSH funcionando, credenciales guardadas) por si algo sale mal y necesitas revertir los cambios. Créeme, esto se agradece.

Si tu hosting no te deja tocar la configuración de Nginx, quizá valga la pena migrar a un proveedor que sí lo permita; en RedServicio ofrecemos planes VPS con acceso completo para este tipo de configuraciones.

Cómo crear el archivo de contraseñas con htpasswd

Primero, el archivo con usuario y contraseña cifrados. La herramienta de siempre es htpasswd, incluida en el paquete apache2-utils (Debian/Ubuntu) o httpd-tools (CentOS/AlmaLinux). ¿No la tienes? Se instala en un momento:

En Debian/Ubuntu: sudo apt install apache2-utils

En CentOS/RHEL: sudo yum install httpd-tools

Para crear el archivo por primera vez, usa la opción -c. Ojo con esto: la opción crea el archivo, así que cuando añadas más usuarios adelante, omítela o sobrescribirás todo:

sudo htpasswd -c /etc/nginx/.htpasswd tunombre

El sistema te pedirá la contraseña dos veces y la almacenará cifrada con el algoritmo bcrypt (según versión, puede usar APR1-MD5 por defecto). Para añadir un segundo usuario sin borrar el primero:

sudo htpasswd /etc/nginx/.htpasswd otrousuario

¿Todo bien? Compruébalo con cat /etc/nginx/.htpasswd. Deberías ver una línea con el usuario seguido de una cadena cifrada. Si aparece, sigues adelante.

Configuración de Nginx: bloques location y ejemplos de código

Toca abrir la configuración del servidor. Suele estar en /etc/nginx/sites-available/tudominio.conf o dentro del bloque server que corresponda a tu sitio. Ahí definiremos un bloque location específico para wp-admin, que es donde está la clave de todo esto:

1. Bloque principal para wp-admin: añade lo siguiente dentro del bloque server:
   
   location ^~ /wp-admin {
    auth_basic "Área restringida";
    auth_basic_user_file /etc/nginx/.htpasswd;
    try_files $uri $uri/ /index.php?$args;
}
2. Proteger también wp-login.php: ojo con este archivo, porque queda fuera de /wp-admin y es puerta de entrada igualmente. Merece la misma protección:
   
   location = /wp-login.php {
    auth_basic "Área restringida";
    auth_basic_user_file /etc/nginx/.htpasswd;
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
}

Ese modificador ^~ del primer bloque no está ahí por capricho. Garantiza que Nginx dé prioridad a esta regla por encima de otras expresiones regulares que puedas tener en la configuración. Si te lo saltas, es de los fallos más frecuentes. Otra cosa: si tu socket de PHP-FPM es distinto (digamos php7.4-fpm.sock), ajusta la ruta. Lo más sencillo es copiar el include y el fastcgi_pass que ya usas en tu bloque PHP existente. Coherencia ante todo.

¿Guardaste? Pues valida la sintaxis y recarga:

nginx -t && systemctl reload nginx

Si el test sale bien, al entrar en tudominio.com/wp-admin el navegador debería pedirte usuario y contraseña antes de mostrar el formulario de WordPress. Y si en cambio te aparece un 404 o un 500, casi seguro que el bloque PHP no quedó bien duplicado dentro del nuevo location. Revisa eso primero.

Excepciones útiles: permitir admin-ajax.php sin contraseña

Aquí viene un detalle que a más de uno le ha vuelto loco. Muchos temas y plugins cargan funciones del frontend a través de admin-ajax.php, que vive dentro de /wp-admin. Si proteges la carpeta entera, esas peticiones mueren con un 401. Resultado: carritos de compra rotos, formularios que no envían, búsquedas en vivo que se quedan colgadas. La solución es sencilla, una excepción:

location = /wp-admin/admin-ajax.php {
    allow all;
    auth_basic off;
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
}

Importante: colócalo antes del location general de /wp-admin. Al tratarse de una coincidencia exacta (=), Nginx la procesa con prioridad y el archivo queda accesible públicamente, que es justo como WordPress espera que funcione.

• Restringe por IP: si siempre entras desde ubicaciones fijas, combina la autenticación básica con directivas allow / deny. Doble cerradura.
• Cuidado con la REST API: hay protecciones agresivas que terminan bloqueando también /wp-json. Tras aplicar los cambios, comprueba que tus integraciones siguen vivas.
• Anota tus credenciales: los navegadores no siempre recuerdan bien estas contraseñas en el móvil. Guárdalas en un gestor, no en un post-it.

Conclusión: seguridad en capas para tu WordPress

Pocas medidas dan tanto por tan poco. La autenticación básica en Nginx detiene el 99% de los ataques de fuerza bruta antes de que siquiera lleguen a WordPress, se monta en minutos y apenas consume recursos. Difícil de batir en relación coste-beneficio. Ahora bien, yo no lo vería como una solución única: la seguridad de verdad se construye en capas. Contraseñas robustas, autenticación en dos pasos, actualizaciones al día, un plugin como Wordfence o Sucuri, certificado SSL y copias de seguridad automatizadas. Cada pieza cubre lo que la anterior deja pasar. Y si prefieres no tocar configuraciones de servidor por tu cuenta, en RedServicio te lo ponemos fácil: nuestros planes de hosting web incluyen servidores optimizados para WordPress, caché, SSL gratuito y soporte técnico 24/7 que puede aplicar este tipo de configuraciones por ti. Tu web merece una defensa sólida. Empieza por blindar wp-admin hoy mismo.