Tutte le guide
NGINX HOSTING

Lista di controllo di hosting Nginx VPS: domini, TLS e test di distribuzione

Segui questa lista di controllo di hosting Nginx VPS per verificare domini, host virtuali, TLS, log e ricarica prima di pubblicare il tuo sito web.

Identificare chi possiede la configurazione Nginx

Nginx può servire file statici, passare richieste PHP a un processo FastCGI o richieste di proxy a un'altra applicazione. Questa lista di controllo presuppone che si amministra il Linux VPS e può controllare la sua configurazione installata. La selezione di una distribuzione VPS non significa che Nginx, PHP, i certificati o un pannello di controllo sono già stati installati e configurati.

Se un pannello gestisce lo stack, utilizza il flusso di lavoro di configurazione supportato. Una modifica manuale a un file generato può essere sovrascritta dal pannello in seguito. Registrare il pacchetto installato, il percorso di configurazione attivo e la persona responsabile per le versioni future prima di aggiungere un secondo sistema che tenta anche di gestire domini o certificati.

Mappa ogni hostname al blocco server previsto

Nginx seleziona un blocco server utilizzando l'indirizzo di ascolto e il nome del server richiesto. Ascolti la recensione e server_name insieme, tra cui un default deliberato per richieste non abbinate. Il puntamento DNS all'VPS non garantisce che il sito web corretto risponda: il server web ha anche bisogno di una configurazione host appropriata.

Elenca il nome host primario, qualsiasi alias www e il comportamento redirect previsto. Testare ogni hostname contro la destinazione utilizzando il dominio previsto prima di cambiare i record pubblici. Un test contro l'IP nudo può raggiungere un sito predefinito e perdere un problema nel sito web nominato.

Scorrere il tavolo orizzontalmente se necessario.

Documentare la destinazione di richiesta prima di distribuire
ArticoloDecisione di registrazioneTest
Dominio e aliasChe server_name gestisce ogni hostOgni hostname serve o reindirizza al sito previsto
root del documentoDove vivono i file pubblici previstiUn patrimonio pubblico noto carichi; i file privati non
Manipolatore di applicazioneproxy statico, FastCGI o inversoUn vero e proprio percorso di applicazione raggiunge il corretto processo
Richieste ineguagliabiliIl comportamento del server predefinito deliberatoI nomi host non noti non visualizzano un'applicazione privata

Collegare i domini e verificare il pubblico DNS

Controllare i file statici, PHP e routing proxy separatamente

Per il contenuto statico, confermare la radice del documento e le autorizzazioni di file utilizzate dal processo di lavoratore. Per PHP, Nginx ha bisogno di una destinazione di lavoro FastCGI e di parametri corretti dello script-path; un file PHP collocato in una directory non è sufficiente. Verificare l'orbita o l'endpoint installato PHP-FPM e le regole di routing specifiche dell'applicazione piuttosto che copiare un percorso da un'altra distribuzione.

Per un'applicazione inversa, verificare che il processo a monte sia in esecuzione al punto finale configurato e che comprenda il nome host pubblico e il contesto HTTPS. Testare un normale percorso di applicazione, un asset e un percorso mancante. Tenere le credenziali, le esportazioni di database e i file dell'ambiente delle applicazioni al di fuori dell'area di conservazione dei file pubblici.

Confronta le opzioni Docker VPS per un'applicazione basata su container

Convalida HTTPS e proprietà di rinnovo del certificato

Un blocco server HTTPS ha bisogno del certificato e della chiave privata corrispondente di riferimento dalla configurazione installata. Verifica la copertura del certificato per ogni hostname pubblico e la catena servita ai clienti. La chiave privata ha bisogno di accesso limitato pur rimanendo leggibile dal processo che lo carica; non deve essere collocato nella radice del documento o inviato in un messaggio di supporto.

Decidi quale strumento o operatore ottiene e rinnova i certificati. Prova il metodo di rinnovo e ispeziona la sua configurazione risultante prima di affidarsi a esso. Controllare il HTTP-to-HTTPS e alias reindirizza per loop, quindi caricare le risorse di applicazione su HTTPS per catturare problemi di contenuto misto. Configurazione del certificato sul proprio VPS è un'attività di amministrazione, non un'inclusione del piano presupposto.

Preparare un'applicazione Node.js dietro un proxy inverso VPS

Configurazione del test prima di applicare un reload

Mantenere una copia dell'ultima configurazione di lavoro e sapere quali sono i file che il cambiamento influisce. Su un'installazione utilizzando il normale eseguibile e percorso, sudo nginx -t controlla la sintassi di configurazione e tenta di aprire file di riferimento. Un test fallito deve essere corretto prima di applicare il cambiamento. Utilizzare il percorso di comando appropriato e il privilegio per il sistema.

Applicare un cambiamento convalidato attraverso il flusso di lavoro di gestione del servizio esistente; Nginx supporta anche il ricarico di nginx -s quando utilizzato per l'istanza in esecuzione prevista. Controllare il risultato del comando e i log, quindi ripetere i test del sito. La validazione della sintassi non può dimostrare che un'applicazione a monte funziona, che DNS è corretta o che un login completa.

Utilizzare i registri di richiesta e di errore per individuare lo strato di guasto

Ispezionare la destinazione di accesso configurato piuttosto che assumere ogni pacchetto scrive allo stesso percorso. Confermare che una richiesta di prova è registrata per l'host atteso e rivedere il suo stato. Se manca una richiesta, controlla la destinazione e qualsiasi configurazione di registrazione prima di concludere che l'applicazione non ha mai ricevuto traffico.

Errori di server web separati da errori di applicazione. Un file mancante, un upstream non disponibile e un login di applicazione fallito hanno bisogno di diverse indagini. Rivedere i messaggi pertinenti senza pubblicare registri grezzi che contengono dati personali, gettoni o stringhe di query sensibili. Disporre la rotazione del registro e la ritenzione per il proprio sistema così utili diagnostica non consumano lo spazio richiesto dal sito.

Verificare il rilascio e rendere ripetibile il rollback

Testare il sito pubblico dopo la ricarica e qualsiasi cambiamento DNS. Includere la homepage, importanti link profondi, il comportamento di upload o form e gli alias HTTPS che supporta. Confermare che i file deliberatamente privati sono inaccessibili. Se l'applicazione utilizza una migrazione di database, rivedere la sua procedura di recupero separatamente dal rollback di configurazione Nginx.

Mantenere il rilascio e la configurazione dell'applicazione precedente fino a quando la nuova release non è stata accettata. Registrare ciò che è cambiato e l'assegno che giustifica la deviazione. Un rollback di blocco server non inverte i dati dell'applicazione scritti dopo il lancio. Utilizzare la guida Docker per la rete di container e la guida di sicurezza per l'indurimento di server più ampi; questa lista di controllo possiede i controlli di distribuzione web-server.

  • Ogni hostname raggiunge il sito e il certificato previsto.
  • Le attività e le percorsi applicativi statici utilizzano il gestore previsto.
  • Configurazione validazione e ricarica completata con successo.
  • Sono disponibili registri, istruzioni di rilascio e ripristino precedenti.

Recensione Docker volumi e rete di containerConfronta Linux VPS piani per lo stack distribuito

Confronta le configurazioni Linux VPSAltre guide