Nginx Server Block Generator

An NGINX server block is the part of a web server configuration that decides which hostnames a request should match and what NGINX should do after the match. The same host can serve static files, pass PHP requests to PHP-FPM, or proxy every request to an application service. The block also carries operational details such as ports, TLS certificate paths, logs, redirects, and small protection rules.

The risk in a server block is rarely the number of lines. A wrong server_name can send traffic to the wrong block. A broad document root can expose private files. A reverse proxy that omits forwarded headers can make the upstream app build wrong redirects or logs. A certificate path that looks right on a workstation can fail when the NGINX master process reads it during reload.

A generated draft should be read as a starting point for review, not as confirmation that the live host is ready. DNS, certificate coverage, readable paths, loaded modules, backend health, and syntax testing all sit outside the text generator. A clean draft still needs to pass the target server's own checks before reload.

Good server-block work answers four questions clearly. Which hostnames should answer? Should HTTP redirect to HTTPS or serve content directly? Should requests go to files, PHP-FPM, or an upstream app? Which warnings must be cleared before the block reaches production change control?

Technical Details:

NGINX first narrows a request by the local address and port named in listen. Within that listen set, server_name matching and the Host header decide which server block should handle the request. If no name matches, the default server for that listen address and port handles the request, so a generated block is only one part of the full virtual-server order on the host.

TLS adds one more timing detail. Server Name Indication can choose a server during the SSL handshake before the HTTP Host header is processed. Certificate files, protocol choices, and the served names must therefore agree with the hostname policy. A block that redirects www to an apex host still needs certificate coverage for any HTTPS name that reaches the HTTPS listener.

The generated text uses three content paths. Static and PHP-FPM modes emit a root, index list, and location / with the selected try_files pattern. PHP-FPM mode adds a PHP regular-expression location with fastcgi_params, SCRIPT_FILENAME, DOCUMENT_ROOT, and the selected FastCGI target. Reverse proxy mode emits one location / with proxy_pass, HTTP/1.1, Host, X-Real-IP, X-Forwarded-For, X-Forwarded-Proto, and X-Forwarded-Host headers, plus optional WebSocket upgrade headers.

The activation commands are review aids, not a substitute for the target server's final syntax check. The generated checklist separates save location, root or backend check, enable path, nginx -t, reload, DNS or certificate check, and curl -I smoke test so each assumption can be tested in order.

Everyday Use & Decision Guide:

Start with Server name, Site mode, www handling, and TLS plan. Those fields decide the served hostname, content handoff, redirect policy, and whether the generated file contains HTTP, HTTPS, or both. If the summary says Needs edits, clear the alert before reading the generated text as a real draft.

For static and PHP sites, check Document root before changing advanced options. The path should usually end at the public web directory rather than the project root. For PHP-FPM, keep the request routing aligned with the app front controller and check that the emitted fastcgi_pass target matches the actual socket or service port.

For reverse proxy mode, the backend URL is the first trust check. A local app at http://127.0.0.1:3000 is a normal target, but it still has to answer from the NGINX host. Turn on WebSocket upgrade headers only for routes that really upgrade the connection, such as Socket.IO or native WebSocket endpoints.

• Use Serve apex and www in one block only when both names should return the same content without redirecting.
• Use Redirect www to apex or Redirect apex to www after choosing the canonical host for links, cookies, and certificates.
• Use HTTP redirect plus HTTPS server block when port 80 should send visitors to HTTPS and port 443 should serve the content block.
• Keep Dotfile protection on for ordinary public file roots unless the app explicitly serves hidden paths outside .well-known.
• Turn on static asset caching only when filenames are versioned or otherwise safe to cache for seven days.
• Use Basic security headers only when the application does not already send stricter or conflicting response headers.

Treat Review before deployment as a real pause. Warnings such as HTTP-only output, unusual document root, wildcard names, cache assumptions, or certificate coverage do not always make the draft wrong, but they point at choices that should be approved before copying the config.

Step-by-Step Guide:

Use the page to draft one host policy, inspect the generated directives, then validate the saved file on the target NGINX server.

1. Enter Server name. The summary should show the canonical hostname; if it shows Needs edits, fix the alert that asks for a host without protocol, path, port, or wildcard.
2. Choose Site mode. Static and PHP-FPM modes should expose Document root; reverse proxy mode should expose Backend URL and show proxy_pass in Directive Ledger.
3. Set www handling and any Extra server names. Open Directive Ledger and confirm served names and redirect-only names match the DNS and certificate plan.
4. Choose TLS plan. If HTTPS is enabled, review Certificate paths and confirm NGINX Server Block contains ssl_certificate, ssl_certificate_key, and ssl_protocols TLSv1.2 TLSv1.3.
5. Set routing details. For static sites, choose a strict 404 or single-page app fallback; for PHP-FPM, use the PHP front controller when requests should flow through /index.php; for proxy mode, test the backend URL separately.
6. Open Advanced only for host-specific changes such as bind address, ports, index files, upload body size, log directory, static cache, WebSocket upgrade headers, or install path style.
7. Read the alert area. Do not copy the config while Fix these inputs before deployment is active, because the generated body is replaced by comment lines explaining the blockers.
8. Open Activation Checklist. Use the save target, root or backend check, include step, sudo nginx -t, reload command, DNS or certificate check, and smoke test as the deployment review sequence.
9. After syntax and smoke tests pass, repeat the request check for any redirected hostnames and extra names listed in Directive Ledger.

Interpreting Results:

NGINX Server Block is the draft configuration text. Directive Ledger explains the important emitted directives, generated size, required module surface, and review notes. Activation Checklist turns the draft into concrete host checks. The JSON view mirrors the same inputs, warnings, errors, directives, checklist rows, and config text.

The summary badge is a page result, not proof of a live server result. Ready means the current fields did not trigger known blockers or warnings. It does not mean NGINX can read the files, the certificate is valid for the host, DNS points at the server, PHP-FPM is accepting requests, or the upstream app is healthy.

The most important checks happen after copying the draft: save it where the local package includes it, confirm paths or upstreams, run nginx -t, reload, and test the exact hostnames the block is meant to answer.

Worked Examples:

Static site moving to HTTPS

A public static site uses Server name example.org, Site mode Static files or single-page app, www handling Redirect www to apex, TLS plan HTTP redirect plus HTTPS server block, and Document root /var/www/example.org/public. NGINX Server Block should contain an HTTP redirect block and an HTTPS content block. Directive Ledger should list server_name, listen, root, TLS, logs, and dotfile protection. Activation Checklist still needs DNS and certificate checks before reload.

PHP-FPM app with front controller routing

A PHP app uses Server name app.example.net, Site mode PHP-FPM application, Document root /srv/app/current/public, PHP-FPM target /run/php/php8.3-fpm.sock, and Request routing PHP front controller /index.php. The generated block should include try_files $uri $uri/ /index.php$is_args$args; and a PHP location with fastcgi_pass unix:/run/php/php8.3-fpm.sock. If the document root warning appears, confirm the path ends at the public directory before using the draft.

Reverse proxy with WebSocket traffic

An app listens at http://127.0.0.1:3000 and uses WebSocket upgrades. Set Site mode to Reverse proxy to app server, enter that Backend URL, and turn on WebSocket upgrade headers. Directive Ledger should show proxy_pass and forwarded-header coverage. The generated block should contain proxy_http_version 1.1, Host, X-Real-IP, X-Forwarded-* headers, plus Upgrade and Connection when the WebSocket switch is on.

Troubleshooting a blocked body-size value

If client_max_body_size is entered as sixteen megabytes, Fix these inputs before deployment should say the value must look like 16m, 1g, or a whole byte count. The config body is replaced by comments until the value is corrected or left blank. That block is intentional because a malformed directive would make the target syntax test fail.

Security and Privacy Notes:

Generation happens in the browser after the page loads. The page has no separate remote service for building the NGINX draft, so hostnames, internal paths, backend URLs, and generated config are handled by the page logic during the session.

Treat the output as infrastructure-sensitive text. It can include internal hostnames, private IP addresses, certificate paths, socket paths, log paths, and upstream service names. Review it through the same approval path used for other web server configuration.

FAQ:

Glossary:

Server block

The NGINX configuration block that listens on one or more addresses and decides how matching hostnames are served.

server_name

The hostname list NGINX compares with the request host after a listen address and port have matched.

SNI

Server Name Indication, the TLS handshake hostname signal used before HTTP request processing.

try_files

The routing directive that checks file paths in order and falls back to a static error, single-page app entry, or PHP front controller.

PHP-FPM

The FastCGI process manager that can execute PHP requests handed off by NGINX.

proxy_pass

The directive that forwards requests from NGINX to an upstream HTTP service.

References:

• Server names, NGINX documentation.
• How nginx processes a request, NGINX documentation.
• Module ngx_http_core_module, NGINX documentation.
• Module ngx_http_proxy_module, NGINX documentation.
• Module ngx_http_ssl_module, NGINX documentation.
• Module ngx_http_gzip_static_module, NGINX documentation.