Nginx VPS lista de verificação de hospedagem: domínios, TLS e testes de implantação

Identificar quem possui a configuração Nginx

Nginx pode servir arquivos estáticos, passar pedidos PHP para um processo FastCGI ou solicitações proxy para outra aplicação. Esta lista de verificação assume que você administra o Linux VPS e pode inspecionar sua configuração instalada. Selecionar uma distribuição VPS não significa Nginx, PHP, certificados ou um painel de controle já foram instalados e configurados.

Se um painel gerenciar a pilha, use seu fluxo de trabalho de configuração suportado. Uma edição manual para um arquivo gerado pode ser sobrescrita pelo painel mais tarde. Grave o pacote instalado, o caminho de configuração ativa e a pessoa responsável por futuras versões antes de adicionar um segundo sistema que também tenta gerenciar domínios ou certificados.

Mapear cada máquina para o bloco do servidor pretendido

Nginx seleciona um bloco de servidor usando o endereço de escuta e o nome do servidor solicitado. Reveja ouvir e server_name juntos, incluindo um padrão deliberado para pedidos inigualáveis. DNS apontando para o VPS não garante que o site correto irá responder: o servidor web também precisa de uma configuração de host adequada.

Listar o nome principal da máquina, qualquer alias www e o comportamento de redirecionamento esperado. Teste cada hostname contra o destino usando seu domínio pretendido antes de alterar registros públicos. Um teste contra o IP nu pode chegar a um site padrão e perder um problema no site nomeado.

Role a tabela horizontalmente, se necessário.

Conecte domínios e verifique DNS público

Verificar arquivos estáticos, PHP e roteamento proxy separadamente

Para conteúdo estático, confirme a raiz do documento e as permissões de arquivo usadas pelo processo do trabalhador. Para PHP, Nginx precisa de um destino FastCGI funcional e parâmetros corretos do caminho do script; um arquivo PHP colocado em um diretório não é suficiente. Verifique o socket ou endpoint instalado do PHP-FPM e as regras de roteamento específicas da aplicação em vez de copiar um caminho de outra distribuição.

Para uma aplicação de aproximação reversa, verifique se o processo upstream está em execução no endpoint configurado e que ele entende o hostname público e o contexto HTTPS. Teste uma rota de aplicação normal, um activo e uma rota em falta. Mantenha credenciais, exportações de banco de dados e arquivos de ambiente de aplicação fora da área pública de arquivos-servir.

Compare as opções Docker VPS para um aplicativo baseado em container

Validar a propriedade HTTPS e renovação de certificados

Um bloco de servidor HTTPS precisa do certificado e da chave privada correspondente referenciada pela configuração instalada. Reveja a cobertura do certificado para cada hostname público e a cadeia servia aos clientes. A chave privada precisa de acesso restrito enquanto permanece legível pelo processo que a carrega; não deve ser colocada na raiz do documento ou enviada em uma mensagem de suporte.

Decida qual ferramenta ou operador obtém e renova os certificados. Teste o método de renovação e inspecione sua configuração resultante antes de confiar nele. Verifique o HTTP-to-HTTPS e os redirecionamentos de alias para loops, então carregue os ativos do aplicativo sobre o HTTPS para detectar problemas de conteúdo misto. A configuração do certificado em seu próprio VPS é uma tarefa de administração, não uma inclusão de plano assumida.

Prepare uma aplicação Node.js atrás de um proxy inverso VPS

Testar a configuração antes de aplicar uma recarga

Mantenha uma cópia da última configuração de trabalho e saiba quais os arquivos incluídos que sua alteração afeta. Em uma instalação usando o executável normal e caminho, sudo nginx -t verifica sintaxe de configuração e tenta abrir arquivos referenciados. Um teste falhou precisa ser corrigido antes de aplicar a alteração. Use o caminho de comando apropriado e privilégio para o seu sistema.

Aplicar uma alteração validada através do fluxo de trabalho de gerenciamento de serviços existente; Nginx também suporta reload nginx -s quando usado para a instância de execução pretendida. Verifique o resultado do comando e logs, em seguida, repita os testes do site. A validação de sintaxe não pode provar que uma aplicação upstream funciona, que o DNS está correto ou que um login termina.

Usar os registos de pedidos e erros para localizar a camada em falha

Inspecione o destino do log de acesso configurado ao invés de assumir que cada pacote escreve para o mesmo caminho. Confirmar que um pedido de teste é gravado para o hospedeiro esperado e rever o seu estado. Se faltar uma solicitação, verifique o destino e qualquer configuração de registro antes de concluir que a aplicação nunca recebeu tráfego.

Separe erros de servidor web dos erros de aplicação. Um arquivo em falta, um upstream indisponível e um login de aplicativo falhou precisam de investigações diferentes. Reveja mensagens relevantes sem publicar registros brutos que contenham dados pessoais, fichas ou strings de consulta sensíveis. Organize rotação de log e retenção para o seu próprio sistema para diagnósticos úteis não consumir o espaço exigido pelo site.

Verifique a liberação e faça o retorno repetível

Teste o site público após a recarga e qualquer alteração DNS. Inclua a página inicial, links profundos importantes, o comportamento de upload ou formulário e os aliases HTTPS que você suporta. Confirme que os arquivos privados são inacessíveis. Se o aplicativo usa uma migração de banco de dados, rever seu procedimento de recuperação separadamente do rollback de configuração Nginx.

Mantenha a versão e configuração da aplicação anterior até que a nova versão seja aceita. Grave o que mudou e o cheque que justificaria revertê-lo. Um rollback do bloco de servidor não reverterá os dados da aplicação escritos após o lançamento. Use o guia Docker para redes de contêineres e o guia de segurança para endurecimento mais amplo do servidor; esta lista de verificação possui as verificações de implantação do servidor web.

• Cada nome de máquina atinge o site e certificado pretendidos.
• Os ativos estáticos e as rotas de aplicação usam o manipulador esperado.
• A validação da configuração e a recarga completaram com sucesso.
• Os logs, as instruções de lançamento e recuperação anteriores estão disponíveis.

Revisão Docker volumes e rede de contêineres · Compare os planos do Linux VPS para a pilha implantada