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
Tema
Decisión sobre el registro
Prueba
Dominio y alias
Que server_name maneja cada host
Cada nombre de host sirve o redirige al sitio indicado
Document root
Donde viven los archivos públicos previstos
Carga de activos públicos conocidos; archivos privados no
Manejador de aplicaciones
Static, FastCGI o proxy inverso
Un camino de aplicación real alcanza el proceso correcto
Solicitudes no cumplidas
El comportamiento deliberado del servidor predeterminado
Nombres de host desconocidos no muestran una aplicación privada
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.
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.
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.
Configurar las teclas SSH para un Linux VPS: crear una clave localmente, instalar la clave pública y probar una segunda conexión antes de cambiar la configuración de inicio de sesión.
Conecte un dominio existente a su alojamiento utilizando los detalles DNS suministrados. Compruebe los registros del sitio web, preservar la configuración de correo electrónico y verificar HTTPS después del cambio.
Prepare acceso SSH, mantenimiento, controles de firewall y copias de seguridad recuperables para un Linux VPS. Probar cambios antes de exponer su aplicación.
Prepare Docker en un Linux VPS: seleccione configuración compatible, servicios de tamaño, proteja datos persistentes y verifique los puertos publicados antes del despliegue.
Elija un enfoque de gestión VPS: administración directa, Cockpit o HestiaCP. Compruebe las opciones de sistema operativo y preparación antes de configurar su servidor.
Productos para comparar
Compruebe las especificaciones y condiciones de estas ofertas antes de elegir.