Modificare le pagine di Errore Personalizzate in Nginx Proxy Manager

da | Mar 16, 2026

 

In questo articolo ti guido passo passo per fare in modo che tutte le richieste gestite da Nginx Proxy Manager usino le stesse pagine di errore personalizzate (400, 401, 402, 403).

Ti spiego pensando a un’installazione tipica con Docker + docker-compose. Se non usi Docker, puoi comunque seguire la logica, ma i percorsi potrebbero cambiare leggermente.

Con Nginx Proxy Manager (NPM) in Docker hai due strade pulite per avere error pages personalizzate:

Globale (vale per tutti i proxy host): metti i file HTML in un posto “fisso” e fai in modo che NPM li serva + un blocco error_page che rimappa tutti i codici.

Per singolo Proxy Host: stessa cosa ma aggiungi la config solo su quel host.

CONFIGURAZIONE GLOBALE

🧩 STEP 1 – Mettere i file di errore sul server

Entrare via SSH nel server dove gira Nginx Proxy Manager quindi creare le seguenti cartelle per le pagine di errore con i comandi:

Creare quindi il file di configurazione server_proxy.conf con il comando:

 

📦 STEP 2 – Montare la cartella nel container NPM

Aprire il docker-compose.yml (quello con il servizio app / nginxproxymanager).

Dentro la sezione volumes: del servizio NPM aggiungere una riga per la cartella:

ATTENZIONE: non rimuovere i volumi esistenti aggiungere solo la riga – ./error_pages:/data/error_pages

Salvare e chiudere il file di configurazione.

Riavviare NPM con i seguenti comandi:

Ora dentro il container i file saranno visibili in:

 

🌍 STEP 3 – Creare una configurazione Nginx globale

In questa sezione faremo in modo che la configurazione venga caricata da tutti i VirtualHost generati da NPM.

Editare il file server_proxy.conf posizionato nella cartella /data/nginx/custom folder con il comando:

Incollare dentro il file di configurazione questo contenuto:

Salvare e chiudere il file di configurazione.

Spiegazione veloce:

error_page …: dice a Nginx quale URL usare per ogni codice di errore.

location /error_pages/: dice dove trovare fisicamente i file (root /data; → quindi /data/error_pages/400.html ecc.)

internal: fa sì che le pagine non siano raggiungibili direttamente via browser (solo tramite error_page).

Nginx Proxy Manager carica automaticamente i file in data/nginx/custom/*.conf all’interno dei blocchi server generati.

In questo modo tutti i proxy host avranno queste direttive senza doverle reinserire a mano in ogni Advanced → Custom Nginx Configuration

🔁 STEP 4 – Riavviare Nginx Proxy Manager

Dopo aver creato il file .conf riavviare il container con i seguenti comandi:

Questo fa rileggere tutte le configurazioni a Nginx.

✅ STEP 5 – Testare le pagine di errore

Ora testare le seguenti cose:

  • Una pagina che dia 403 (ad esempio una location protetta)
  • Una richiesta che generi 400 (URL volutamente malformato o qualche backend che risponde 400)
  • Analogamente per 401/402 se hai contesti in cui vengono generati.

In pratica aprire un dominio gestito da NPM

Fare un’azione che generi quell’errore

Se tutto è ok dovresti vedere le pagine personalizzate.

🧪 STEP 6 – Se qualcosa non funziona

Se non vedi le pagine personalizzate eseguire gli steps che elenco di seguito:

  1. Controllare dentro il container che i file siano davvero dove devono essere con i seguenti comandi:

2. Verificare che il file error_pages.conf sia montato correttamente con i seguenti comandi:

3. Analizzare i log di Nginx Proxy Manager con il comando:

 

CONFIGURAZIONE PER SINGOLO HOST

🧩 STEP 1 – Creazione della cartella sul server e dei file HTML

Creare la cartella custom-errors con il comando:

Creare/Copiare i files (uno per codice). Esempio per 404 e 50x:

 

📦 STEP 2 – Montare la cartella dentro il container di NPM

Aprire il file docker-compose.yml di Nginx Proxy Manager (dove hai jc21/nginx-proxy-manager o simile) con il comando:

Aggiungere il volume al fondo della configurazione del file como mostrato di seguito:

Salvare e chiudere il file di configurazione.

Riavviare Docker con il comando:

Verificare che i file siano visibili nel container eseguendo il comando:

Se è tutto OK dovremmo visualizzare il seguente output:

 

🌍 STEP 3 – Creare un server interno per servire quei file (snippet globale)

NPM genera la config di Nginx automaticamente quindi il modo più pratico è usare Advanced config e/o snippet.

Opzione consigliata: Custom Nginx Configuration globale

NPM (di solito) permette snippet globali in /data/nginx/custom/.

Creare una cartella e un file come di seguito:

ATTENZIONE: per usare /data/nginx/custom/ devi avere quel path nel container. In NPM normalmente esiste già in /data/nginx/. Quindi creiamo direttamente dentro i volumi già montati di NPM.

Nel compose montare ./data:/data e sul server la cartella è ./data nella directory del compose.

Ad esempio se il compose sta in /opt/npm/compose/docker-compose.yml allora /opt/npm/compose/data è mappata a /data nel container

Quindi creare la cartella ed il file http.conf con i seguenti comandi:

Dentro http.conf inserire un blocco server interno che serve i file (non esposto su internet) così possiamo fare proxy_intercept_errors e error_page puntando a URI locali:

Salvare e chiudere il file di configurazione.

Quindi riavviare NPM con il comando:

 

🔁 STEP 4 – Agganciare le error pages ai Proxy Host

Ora dobbiamo dire a ogni server/proxy host di:

  • intercettare gli errori (proxy_intercept_errors on;)
  • mappare ogni status code su una URL interna
  • fare un subrequest verso 127.0.0.1:8181

Collegarsi alla gui di NPM

Cliccare su Proxy Hosts come mostrato nell’immagine sovrastante

Cliccare sui tre puntini del Proxy Host che vogliamo modificare quindi selezionare Edit

Cliccare sull’ingranaggio (Advanced)

Incollare all’interno di Custom Nginx Configuration il seguente output:

 

Dopo aver inserito l’output cliccare Save

ATTENZIONE: Accertarsi di avere davvero i file:

/opt/npm/custom-errors/400.html

/opt/npm/custom-errors/505.html

Altrimenti Nginx proverà a prenderli e otterrai un errore.

Ripetere sugli altri Proxy Host dove si intende applicare questa configurazione.

✅ STEP 5 – Testare le pagine di errore

Test 404: apri una URL inesistente sul dominio

Test 502/504: fermare temporaneamente l’app upstream e provare ad aprire il dominio

Dovremmo visualizzare la pagina di errore caricata in precedenza

Se invece vediamo la pagina standard di Nginx vuol dire che c’è qualcosa che non ha funzionato nella configurazione.

Controllare quindi i log Nginx di NPM con il comando:

 

🧪 STEP 6 – Note importanti (per evitare sorprese)

401/403: spesso dipendono da auth (basic auth, app, access list). NPM può intercettarli se l’errore viene generato dal layer Nginx/proxy.

413 (payload too large): può essere generato da Nginx prima che la richiesta arrivi all’upstream; comunque lo gestisci uguale.

Errori generati dall’app: se la tua app risponde “200” con una pagina “Errore” in HTML, Nginx non lo vede come errore e non lo sostituisce.

Variante più semplice (se vuoi 2 file soltanto). Se vuoi evitare 25 file, puoi creare:

/opt/npm/custom-errors/4xx.html

/opt/npm/custom-errors/50x.html

e rimappare tutti i 4xx e 50x all’interno dei due file.

 

DOWNLOAD TEMPLATE DI ERROR PAGES (HTML/CSS)

Di seguito una serie di link dove è possibile scaricare gratuitamente delle Custom Page già belle e fatte:

Template HTML per pagine 404 – design pronti per essere adattati o modificati: 63 HTML 404 Templates

Collezione di template per error pages HTTP (404, 500, ecc.) su GitHub – HTML gratuiti per sostituire le pagine standard di server web: https://github.com/PecceG2/HTML_Template_http_codes

Raccolta di template gratuiti (404, 500, ecc.) con varie grafiche – spesso con anteprime + codice pronto: https://colorlib.com/wp/free-error-page-templates/?utm_source=chatgpt.com

Template gratuiti 404 in HTML/CSS (16 esempi): https://democoding.in/blogs/free-html-error-page-templates Demo Coding

Raccolta di template 500 error pages (puoi adattarli ad altri errori): https://uicookies.com/500-error-page-templates

Articoli Recenti

Veeam Backup

Monitoring

Friends

  • My English Lab  English School
  • ChrSystem   Servizi ICT
  • Since 01  Kreative Graphics

Database

Networking

Autori

  • Raffaele Chiatto  Amministratore
  • Marco Valle  Autore
  • Angelo Lauria  Autore
  • Edoardo Prot  Autore
  • Davide D’Urso  Autore
Raffaele Chiatto

Raffaele Chiatto

Sono Raffaele Chiatto, un appassionato di informatica a 360 gradi. Tutto è iniziato nel 1996, quando ho scoperto il mondo dell'informatica grazie a Windows 95, e da quel momento non ho più smesso di esplorare e imparare. Ogni giorno mi dedico con curiosità e passione a scoprire le nuove frontiere di questo settore in continua evoluzione.

Related Post

0 commenti

Invia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Virtualizzazione

Linux

Microsoft

Apple

Backup

Database

Security

Automazione