Nginx VPS hosting checklist: domains, TLS and deployment tests

Identify who owns the Nginx configuration

Nginx can serve static files, pass PHP requests to a FastCGI process or proxy requests to another application. This checklist assumes you administer the Linux VPS and can inspect its installed configuration. Selecting a VPS distribution does not mean Nginx, PHP, certificates or a control panel have already been installed and configured.

If a panel manages the stack, use its supported configuration workflow. A manual edit to a generated file may be overwritten by the panel later. Record the installed package, active configuration path and the person responsible for future releases before adding a second system that also tries to manage domains or certificates.

Map each hostname to the intended server block

Nginx selects a server block using the listening address and the requested server name. Review listen and server_name together, including a deliberate default for unmatched requests. DNS pointing at the VPS does not guarantee the correct website will answer: the web server also needs an appropriate host configuration.

List the primary hostname, any www alias and the expected redirect behaviour. Test each hostname against the destination using your intended domain before changing public records. A test against the bare IP can reach a default site and miss a problem in the named website.

Scroll the table horizontally if needed.

Connect domains and verify public DNS

Check static files, PHP and proxy routing separately

For static content, confirm the document root and the file permissions used by the worker process. For PHP, Nginx needs a working FastCGI destination and correct script-path parameters; a PHP file placed in a directory is not enough. Verify the installed PHP-FPM socket or endpoint and the application-specific routing rules rather than copying a path from another distribution.

For a reverse-proxied application, check that the upstream process is running at the configured endpoint and that it understands the public hostname and HTTPS context. Test a normal application route, an asset and a missing route. Keep credentials, database exports and application environment files outside the public file-serving area.

Compare Docker VPS options for a container-based application

Validate HTTPS and certificate renewal ownership

An HTTPS server block needs the certificate and matching private key referenced by the installed configuration. Review certificate coverage for every public hostname and the chain served to clients. The private key needs restricted access while remaining readable by the process that loads it; it should not be placed in the document root or sent in a support message.

Decide which tool or operator obtains and renews the certificates. Test the renewal method and inspect its resulting configuration before relying on it. Check the HTTP-to-HTTPS and alias redirects for loops, then load application assets over HTTPS to catch mixed-content problems. Certificate setup on your own VPS is an administration task, not an assumed plan inclusion.

Prepare a Node.js application behind a VPS reverse proxy

Test configuration before applying a reload

Keep a copy of the last working configuration and know which include files your change affects. On an installation using the normal executable and path, sudo nginx -t checks configuration syntax and attempts to open referenced files. A failed test needs to be corrected before you apply the change. Use the appropriate command path and privilege for your system.

Apply a validated change through the existing service-management workflow; Nginx also supports nginx -s reload when used for the intended running instance. Check the command result and logs, then repeat the website tests. Syntax validation cannot prove that an upstream application works, that DNS is correct or that a login completes.

Use request and error logs to locate the failing layer

Inspect the configured access-log destination rather than assuming every package writes to the same path. Confirm that a test request is recorded for the expected host and review its status. If a request is missing, check the destination and any logging configuration before concluding that the application never received traffic.

Separate web-server errors from application errors. A missing file, an unavailable upstream and a failed application login need different investigations. Review relevant messages without publishing raw logs that contain personal data, tokens or sensitive query strings. Arrange log rotation and retention for your own system so useful diagnostics do not consume the space required by the site.

Verify the release and make rollback repeatable

Test the public site after the reload and any DNS change. Include the homepage, important deep links, upload or form behaviour and the HTTPS aliases you support. Confirm that deliberately private files are inaccessible. If the application uses a database migration, review its recovery procedure separately from the Nginx configuration rollback.

Keep the previous application release and configuration until the new release has been accepted. Record what changed and the check that would justify reverting it. A server-block rollback will not reverse application data written after launch. Use the Docker guide for container networking and the security guide for broader server hardening; this checklist owns the web-server deployment checks.

• Every hostname reaches the intended site and certificate.
• Static assets and application routes use the expected handler.
• Configuration validation and the reload completed successfully.
• Logs, previous release and recovery instructions are available.

Review Docker volumes and container networking · Compare Linux VPS plans for the deployed stack