Todos los guías
NGINX HOSTING

Nginx VPS lista de comprobación de alojamiento: dominios, TLS y pruebas de implementación

Siga esta lista de verificación Nginx VPS para verificar dominios, hosts virtuales, TLS, registros y recargas antes de publicar su sitio web.

Identifica quién es el dueño de la configuración Nginx

Nginx puede servir archivos estáticos, pasar PHP peticiones a un proceso FastCGI o solicitudes de proxy a otra aplicación. Esta lista de verificación supone que administra el Linux VPS y puede inspeccionar su configuración instalada. La selección de una distribución VPS no significa Nginx, PHP, ya se han instalado y configurado certificados o un panel de control.

Si un panel administra la pila, utilice su flujo de trabajo de configuración compatible. Una edición manual a un archivo generado puede ser sobrescrito por el panel más tarde. Grabar el paquete instalado, la ruta de configuración activa y la persona responsable de futuras versiones antes de añadir un segundo sistema que también trate de gestionar dominios o certificados.

Mapa cada nombre de host al bloque servidor previsto

Nginx selecciona un bloque servidor usando la dirección de escucha y el nombre del servidor solicitado. Revise escuchar y server_name juntos, incluyendo un predeterminado deliberado para solicitudes sin igual. DNS señalando en el VPS no garantiza que el sitio web correcto responda: el servidor web también necesita una configuración de host adecuada.

Enumerar el nombre de host primario, cualquier alias www y el comportamiento de redirección previsto. Pruebe cada nombre de host contra el destino utilizando su dominio previsto antes de cambiar los registros públicos. Una prueba contra la IP desnuda puede llegar a un sitio predeterminado y perder un problema en el sitio web llamado.

Desplazar la tabla horizontalmente si es necesario.

Documentar el destino de solicitud antes de desplegar
TemaDecisión sobre el registroPrueba
Dominio y aliasQue server_name maneja cada hostCada nombre de host sirve o redirige al sitio indicado
Document rootDonde viven los archivos públicos previstosCarga de activos públicos conocidos; archivos privados no
Manejador de aplicacionesStatic, FastCGI o proxy inversoUn camino de aplicación real alcanza el proceso correcto
Solicitudes no cumplidasEl comportamiento deliberado del servidor predeterminadoNombres de host desconocidos no muestran una aplicación privada

Conectar dominios y verificar público DNS

Compruebe los archivos estáticos, PHP y el enrutamiento proxy por separado

Para el contenido estático, confirme la raíz del documento y los permisos de archivo utilizados por el proceso del trabajador. Para PHP, Nginx necesita un destino FastCGI de trabajo y parámetros correctos de script-path; un archivo PHP colocado en un directorio no es suficiente. Verifique el socket o punto final de PHP-FPM instalados y las reglas de enrutamiento específicas para aplicaciones en lugar de copiar un camino de otra distribución.

Para una aplicación proxiada inversa, compruebe que el proceso de corriente está funcionando en el extremo configurado y que entiende el nombre de host público y el contexto HTTPS. Prueba una ruta normal de aplicación, un activo y una ruta perdida. Mantener credenciales, exportaciones de bases de datos y archivos de entorno de aplicaciones fuera de la zona de servicio público de archivos.

Comparar opciones Docker VPS para una aplicación basada en contenedores

Validar HTTPS y propiedad de renovación de certificados

Un bloque de servidor HTTPS necesita el certificado y la clave privada que coincide con la configuración instalada. Revise la cobertura de certificados para cada nombre de host público y la cadena servida a los clientes. La clave privada necesita acceso restringido mientras que sigue siendo legible por el proceso que la carga; no debe colocarse en la raíz del documento o enviarse en un mensaje de apoyo.

Decide qué herramienta o operador obtiene y renueva los certificados. Prueba el método de renovación e inspecciona su configuración resultante antes de confiar en él. Compruebe el HTTP-to-HTTPS y alias redirecciona para bucles, luego cargar activos de aplicación sobre HTTPS para atrapar problemas de contenido mixto. La configuración de certificados en su propio VPS es una tarea de administración, no una inclusión de plan asumido.

Prepare una aplicación Node.js detrás de un proxy inverso VPS

Configuración de prueba antes de aplicar una recarga

Mantenga una copia de la última configuración de trabajo y sepa qué incluye archivos afecta su cambio. En una instalación utilizando el eje ejecutable y la ruta normal, sudo nginx -t comprueba la sintaxis de configuración e intenta abrir archivos referenciados. Una prueba fallida necesita ser corregida antes de aplicar el cambio. Utilice el camino de mando y privilegio adecuado para su sistema.

Aplicar un cambio validado a través del flujo de trabajo existente de gestión de servicios; Nginx también admite la recarga de nginx -s cuando se utiliza para la instancia de ejecución prevista. Compruebe el resultado del comando y los registros, luego repetir las pruebas del sitio web. La validación sintaxis no puede demostrar que una aplicación de corriente avanzada funciona, que DNS es correcta o que un login completa.

Use registros de solicitud y errores para localizar la capa de falla

Inspeccione el destino de acceso-log configurado en lugar de asumir que cada paquete escribe al mismo camino. Confirme que se registra una solicitud de prueba para el anfitrión previsto y revise su estado. Si falta una solicitud, compruebe el destino y cualquier configuración de registro antes de concluir que la aplicación nunca recibió tráfico.

Errores separados del servidor web de errores de aplicación. Un archivo perdido, un flujo ascendente indisponible y un login de aplicación fallido necesitan diferentes investigaciones. Revise los mensajes relevantes sin publicar registros brutos que contengan datos personales, fichas o cadenas de consulta sensibles. Organizar la rotación y retención de registros para su propio sistema así que los diagnósticos útiles no consumen el espacio requerido por el sitio.

Verificar la liberación y hacer repetible repetible repetible

Prueba el sitio público después de la recarga y cualquier cambio DNS. Incluya la página principal, enlaces profundos importantes, comportamiento de carga o forma y el alias HTTPS que usted apoya. Confirme que los archivos privados deliberadamente son inaccesibles. Si la aplicación utiliza una migración de bases de datos, revise su procedimiento de recuperación por separado del reverso de configuración Nginx.

Mantenga la versión y configuración previa de la aplicación hasta que se haya aceptado la nueva versión. Grabar lo que cambió y el cheque que justificaría revertirlo. Un servidor-block rollback no revertirá los datos de aplicación escritos después del lanzamiento. Utilice la guía Docker para redes de contenedores y la guía de seguridad para el endurecimiento del servidor más amplio; esta lista de verificación posee los controles de implementación del servidor web.

  • Cada nombre de host alcanza el sitio y certificado deseado.
  • Los activos estaticos y las rutas de aplicación utilizan el manejador esperado.
  • validación de configuración y la recarga completada con éxito.
  • Hay registros, instrucciones anteriores de liberación y recuperación disponibles.

Revisión de volúmenes Docker y redes de contenedoresCompara los planes Linux VPS para la pila desplegada

Compare configuraciones Linux VPSOtras guías