Nato per reggere un gran numero di connessioni simultanee, Nginx si è affermato come server web principale o come reverse proxy collocato davanti ad altri server. WordPress lo raccomanda, insieme ad Apache, tra i server più robusti per ospitare il CMS.
Come funziona Nginx
Secondo la sua documentazione, Nginx avvia un processo master e diversi processi worker. Il master legge e verifica la configurazione e gestisce i worker; sono questi ultimi a trattare le richieste, secondo un modello a eventi. Invece di riservare un processo o un thread a ogni connessione, ciascun worker segue molte connessioni insieme e reagisce appena una di esse è pronta. Il numero di worker si imposta spesso sul numero di core del processore.
La configurazione sta nel file nginx.conf e nei file che include. Una modifica si applica solo dopo un reload (nginx -s reload): il master verifica la nuova configurazione, avvia nuovi worker e ferma con calma quelli vecchi, oppure mantiene la configurazione precedente se la nuova contiene un errore.
Nginx e PHP
Nginx non esegue PHP da solo. Passa gli script a un server FastCGI, quasi sempre PHP-FPM, con la direttiva fastcgi_pass. Il dialogo avviene tramite un socket Unix o una porta locale; la documentazione di PHP avverte che un endpoint FastCGI esposto in rete permette l’esecuzione di codice arbitrario, da cui la preferenza per un socket quando tutto gira sulla stessa macchina.
Niente .htaccess
È la differenza che sorprende di più chi arriva da Apache: la documentazione di WordPress ricorda che Nginx non ha un file di configurazione per cartella come il .htaccess. Tutto si imposta a livello di server, e WordPress non può scrivere da solo le sue regole di riscrittura. Per i permalink la riga essenziale è:
location / {
try_files $uri $uri/ /index.php?$args;
}Serve il file o la cartella richiesti se esistono, altrimenti passa la richiesta a index.php mantenendo i parametri dell’URL. Senza questa riga i permalink personalizzati restituiscono errori 404.
Per WordPress
- Le regole dei plugin non si applicano da sole: un plugin che scrive nel .htaccess (cache, sicurezza, redirect) non ha alcun effetto su Nginx. Bisogna riportarne le regole nella configurazione, o chiedere al provider di hosting di farlo.
- Proteggi l’amministrazione e i file sensibili con blocchi
location, come mostra la nostra guida per proteggere wp-admin a livello di server. - Dietro una CDN o un proxy, configura il modulo real_ip per recuperare l’indirizzo del visitatore; vedi Cloudflare davanti a WordPress.
- Ricarica dopo ogni modifica e prova prima la configurazione con
nginx -t.
WP Masquerade funziona su Nginx senza regole lato server, con due eccezioni: gli alias di file della versione Pro, per i quali il plugin genera il blocco da copiare, e una riga che nasconde la cartella del plugin, come spiega la pagina compatibilità con hosting e cache.
Errori frequenti
Aggiungere protezioni in un .htaccess su un server Nginx e credere il sito protetto; lasciare PHP-FPM in ascolto su un indirizzo raggiungibile da Internet; dimenticare ?$args in try_files, il che rompe gli indirizzi con parametri. Molti provider mettono anche Nginx davanti ad Apache: in quel caso il .htaccess torna a funzionare per le richieste passate ad Apache.