Saltar al contenido
EdgeServers
Blog

Migrar Apache a Nginx — los patrones de traducción y el playbook que usamos

17 de mayo de 2026 · 1 min de lectura · por Sudhanshu K.

Las migraciones Apache-a-Nginx casi siempre se atascan en el mismo punto: .htaccess. El dueño de la aplicación cree que el fichero hace algo irreemplazable. Nueve de cada diez veces es una cadena de RewriteRule que se traduce en dos líneas de config Nginx. La décima vez es una regla mod_rewrite tan laberíntica que la respuesta más segura es arreglar la aplicación en su lugar.

Esta es la tabla de traducción, el runbook y la lista de baches que usamos en cada engagement de Apache-a-Nginx.

La tabla de traducción — las reglas que cubren el 90 % de los casos

# Apache: RewriteRule ^(.*)$ /index.php?route=$1 [L]
location / {
  try_files $uri $uri/ /index.php?route=$request_uri;
}
 
# Apache: Order Deny,Allow / Deny from all
location ~ /\.git { deny all; return 404; }
 
# Apache: AuthType Basic / AuthUserFile
location /admin/ {
  auth_basic "restricted";
  auth_basic_user_file /etc/nginx/.htpasswd;
}

.htaccess no tiene un equivalente limpio en Nginx — y eso es una feature. La configuración vive en un solo sitio, no esparcida por cada directorio de tu webroot.

El artículo completo cubre:

  • Los patrones de mod_rewrite que mapean directamente, y los que necesitan replanteamiento
  • El cableado de PHP-FPM — el bloque FastCGI que copiamos en cada sitio
  • Las rarezas de logging Apache vs Nginx (diferencias de formato combined, niveles de log de error)
  • Patrones de sticky-session y afinidad por cookie en load-balancing
  • El cutover de doble-ejecución (Apache en :8080, Nginx en :443, tráfico modelado en el edge)
  • El smoke test de 24 horas que ejecutamos tras el cutover antes de declarar terminado

Háblanos si te gustaría un segundo par de ojos sobre el tuyo.

Artículo completo disponible

Leer el artículo completo