Nginx Server Block Generator

Request flow visual unavailable.

Server name:

Use a bare host such as example.com or app.example.com.

Site mode:

The selection changes directives, validation, route steps, and activation checks.

Document root:

Point at the public web root, not the whole application repository.

Backend URLs:

Multiple backends must share a scheme and omit paths, queries, and fragments.

PHP-FPM target:

Common Debian path: /run/php/php8.3-fpm.sock.

Request routing:

The selected fallback must agree with the application router.

Canonical host policy:

Every HTTPS-served or redirect-only name still needs matching DNS and certificate coverage.

TLS plan:

Redirect plus HTTPS is the normal public target after DNS and certificate readiness.

Certificate paths:

The browser cannot verify file existence, permissions, chain order, or hostname coverage.

Certificate file:

Example: /etc/ssl/certs/example.com-fullchain.pem

Private key file:

Keep private-key permissions restricted on the target host.

HTTP/2:

Requires an NGINX build with ngx_http_v2_module and TLS ALPN support.

HSTS policy:

Leave off until every affected hostname can stay on HTTPS.

Access policy:

Allowlists depend on the source address NGINX actually sees.

Allowed IPs or CIDRs:

Separate IPv4, IPv6, or CIDR values with whitespace, commas, or semicolons.

Dotfile protection:

Keep enabled for ordinary public file-serving sites.

NGINX layout:

This changes the target path, enable step, and reload service name.

Extra server names:

Leave blank unless DNS and certificate coverage include more names.

Bind address:

Use *, an IPv4 address, or a bracketed IPv6 address.

HTTP port:

Port 80 is standard for public HTTP.

port

HTTPS port:

Port 443 is standard for public HTTPS.

port

Index files:

PHP apps normally place index.php first.

Static asset cache:

Enable only when asset filenames are versioned or otherwise safe to cache.

Dynamic gzip:

Check for an existing http-level compression policy before enabling.

Pre-compressed assets:

Leave off unless the deployment pipeline publishes pre-compressed assets.

WebSocket upgrade:

Enable for WebSocket or similar HTTP upgrade routes.

Load balancing:

The choice has no effect for a single backend.

Proxy connect timeout:

Use a bounded failure time that fits the upstream service.

Proxy read timeout:

Increase deliberately for streaming, long polling, or slow responses.

Client body limit:

Leave blank to inherit the surrounding NGINX limit.

Basic security headers:

Review against stricter application or http-level headers.

Custom response headers:

Confirm NGINX add_header inheritance and application ownership before deploying.

Log directory:

The target NGINX process must be able to open the generated paths.

Review comments:

Comments change readability only, not NGINX behavior.

{{ values.config_text }}

Stage	Status	Generated path	Review cue	Copy
{{ row.stage }}	{{ row.status }}	{{ row.generated }}	{{ row.review }}

Directive	Value	Deployment note	Copy
{{ row.directive }}	{{ row.value }}	{{ row.note }}

Step	Command or check	Reason	Copy
{{ row.step }}	`{{ row.command }}`	{{ row.reason }}

A public hostname reaches an NGINX site through several decisions that must agree. The listener accepts a connection, the server name selects a virtual host, the transport policy decides whether HTTP is served or redirected, and a location rule sends the request to files, PHP-FPM, or an application server. A plausible-looking configuration can still fail when any one of those handoffs points to the wrong place.

A server block is the virtual-host boundary for one site. Its listen directives establish addresses and ports, while server_name identifies the hostnames handled there. Host matching also depends on every other server block sharing the listener, so the surrounding configuration remains part of the result.

Static site: NGINX reads public files from a document root. Missing-path behavior may be a real 404 or a fallback to /index.html for a client-side router.
PHP-FPM site: Static requests still use the document root, while matching PHP requests pass to a FastCGI socket or host and port.
Reverse proxy: NGINX forwards requests to one application origin or an upstream group and supplies the host, scheme, and client-address headers the application may need.

Canonical-host redirects are part of site identity, not cosmetic cleanup. DNS must resolve every served or redirect-only name, and an HTTPS certificate must cover each name that receives a TLS connection before a redirect can occur. Likewise, an allowlist is only as reliable as the client address NGINX actually sees after any load balancer or proxy.

Security switches need staged judgment. HTTP Strict Transport Security (HSTS) tells browsers to return over HTTPS for a declared period, and the subdomain or preload forms can affect more than one host. Cache headers, compression, response headers, body limits, and WebSocket upgrades can also conflict with policies already owned by the application or the enclosing http configuration.

A generated block is therefore a reviewable draft, not evidence that the target host is ready. File existence, certificate chain order, installed modules, included configuration paths, service ownership, upstream reachability, and live DNS can only be checked on the deployment system.

How to Use This Tool:

Begin with the request handoff, then add transport and hardening choices only after the site path is clear.

Enter the canonical Server name and choose Site mode. For static or PHP-FPM service, point Document root at the public directory. For a proxy, enter one absolute backend URL per line.
Choose Request routing for a file-serving site, or confirm the PHP-FPM target or proxy origins. Multiple proxy origins must share a scheme and must not include paths, queries, or fragments.
Set the Canonical host policy and TLS plan. If HTTPS is selected, confirm that the certificate paths and all served or redirected names belong to the same deployment plan.
Add an Access policy, HSTS, caching, compression, headers, timeouts, or body limits only when their owner and effect are known. Treat every Review finding as work to resolve, not as a harmless note.
Save the generated text in the include location for the selected NGINX layout. Run nginx -t before reloading, then test DNS, TLS negotiation, redirects, representative files or routes, and every upstream from the target host.

Interpreting Results:

The generated server block is the deployable draft. The Readiness profile identifies decisions that still depend on the target environment, while the Request route shows the path from listener and hostname through transport, content handoff, guards, and verification.

Ready means the selected values are internally consistent. It does not prove that a file, module, certificate, DNS record, backend, or include path exists.
Review marks a concrete deployment dependency such as HTTP-only service, HSTS preload, certificate-name coverage, a multi-backend upstream block, client-IP handling, or overlapping cache and header policy.
The Activation plan is the safer finish. Stop at the first failed syntax, module, file, upstream, DNS, TLS, redirect, or content check rather than reloading an unverified draft.

Technical Details:

NGINX first chooses a listener and virtual server, then resolves the request inside that server through location rules. The generated configuration keeps host selection, transport, and content handoff as separate decisions so a redirect cannot silently replace the content block or send a request to the wrong application.

Rule Core:

The following order describes the generated decision path. Each stage constrains the next one.

Ordered NGINX server block rules
Stage	Governing rule	Failure to catch
Listener	Bind to the chosen address and port; add TLS only to the secure content or secure redirect block.	Another default server on the same listener may receive the request.
Host identity	Serve the canonical name and any aliases, or place redirect-only names in dedicated blocks.	DNS or certificate coverage may be incomplete even when the syntax is valid.
Transport	Serve HTTP, redirect HTTP to HTTPS, or serve HTTPS without an HTTP listener.	HTTPS-only does not redirect ordinary HTTP traffic; HTTP-only leaves transport unencrypted.
Handoff	Use `try_files`, FastCGI, or `proxy_pass` according to the selected site mode.	A wrong public root, application entry point, socket, or origin breaks requests after host matching succeeds.
Guards	Apply allow/deny rules, hidden-file denial, body limits, headers, caching, and compression around the content path.	Inherited or application-owned policy can conflict with the generated directives.
Activation	Test the merged configuration, reload only after success, then probe the live route.	Browser-side generation cannot inspect the running host.

Content Handoff Map:

Generated content behavior by site mode
Mode	Primary directives	Important generated behavior
Static	`root`, `index`, `try_files`	The fallback is a 404 or `/index.html`. Optional hidden-file denial preserves `/.well-known`.
PHP-FPM	Static rules plus `fastcgi_pass`	The PHP location supplies the real document root and script filename to a Unix socket or network target.
Reverse proxy	`proxy_pass` and forwarded request headers	One origin is used directly. Two or more origins become an `upstream` block with round robin, `least_conn`, or `ip_hash`.

HTTPS output uses TLS 1.2 and 1.3 directives, certificate and key paths, and the current standalone http2 on; form when HTTP/2 is enabled. The HTTP/2 module and Application-Layer Protocol Negotiation (ALPN) support must exist on the target build. HSTS policies emit a one-year max-age; the broader choices also add includeSubDomains and optionally preload.

Validation Boundaries:

Ports must be whole numbers from 1 through 65,535. Proxy connect and read timeouts must be whole seconds from 1 through 86,400.
A document root, custom certificate path, private-key path, and log directory must be absolute paths. A body limit must be a whole byte count or a number followed by k, m, or g.
Multiple proxy backends must be absolute HTTP or HTTPS origins with one shared scheme. A single backend may retain a path; a generated upstream group may not.
Allowlist entries must be valid IPv4, IPv6, or CIDR values. The resulting rule ends with deny all;, so an incorrect real-client-address setup can deny legitimate users.
Custom response headers require one safe Name: Value line each. They still need an inheritance and ownership review in the complete NGINX configuration.

Limitations and Safety Notes:

All generation happens in the browser, but the entered configuration may still contain private hostnames, filesystem paths, network ranges, or authentication-related headers. Avoid placing live secrets in custom headers or shared drafts.

The draft cannot verify files, permissions, modules, included paths, certificate chains, DNS, real client addresses, or backend health.
HSTS preload is difficult to reverse. Enable it only after HTTPS and certificate renewal are dependable for the parent domain and every affected subdomain.
Baseline security headers are intentionally limited. Application-specific Content Security Policy, authentication, rate limiting, and trusted-proxy rules require separate design.

Worked Examples:

PHP application with one canonical hostname

Select PHP-FPM, point the document root at the public directory, choose the front-controller route, redirect www to the apex name, and select HTTP-to-HTTPS. The result separates redirect traffic from the secure content block and passes PHP requests to the chosen socket. Before activation, confirm both DNS names and the certificate, then run the syntax test and request the home page plus one missing route.

Two application origins behind NGINX

Choose Reverse proxy and enter two bare origins with the same scheme. The result creates one upstream group and points proxy_pass at it. A Review item remains because the upstream block must be loaded in the HTTP context; probe both origins from the NGINX host and check that the selected balancing policy matches the traffic pattern.

References:

How nginx processes a request, NGINX.
Core module documentation for try_files, NGINX.
HTTP/2 module documentation, NGINX.
How to enable HTTP/2 in Nginx, Simplified Guide.
How to improve Nginx security, Simplified Guide.