Nginx Server Block Generator

Stage	Generated path	Review cue	Copy
{{ row.stage }}	{{ 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 request can reach the right NGINX process and still land in the wrong virtual host. NGINX first compares the local address and port from the listen directives, then uses the HTTP Host name within that matching set. If no name matches, the default server for that address and port handles the request. That default behavior is useful, but it is also why a missing hostname, an old sample block, or a broad wildcard can make a new site appear to ignore its own configuration.

A server block is the per-site policy that joins those early matching rules to the actual content handoff. For a static site, it usually names a public document root and a try_files fallback. For a PHP application, it still has a root, but PHP files are passed to PHP-FPM over FastCGI. For a reverse proxy, NGINX receives the client request and forwards it to an upstream application while deciding which client, host, and scheme headers the app should see.

Common NGINX server block handoff patterns
Pattern	What NGINX owns	Common risk
Static site	File lookup, directory indexes, cache headers, and fallback behavior.	Pointing `root` at a whole app directory instead of a public web root.
PHP-FPM app	Static files plus FastCGI handoff for PHP scripts.	Using the wrong socket, service port, or script filename mapping.
Reverse proxy	Client-facing host, TLS, redirects, and forwarding to an app origin.	Dropping or trusting forwarded headers without matching app-side policy.
Upstream group	Several backend origins behind one named target.	Placing the upstream definition where the main NGINX file does not include it.

Listener

address and port

Host match

server_name

Transport

HTTP or TLS

Handoff

files, PHP, proxy

Verify

syntax and request

TLS changes the review order because certificate selection happens during the handshake, before a normal HTTP request is processed. Any HTTPS name that can reach a listener, including a hostname that only redirects, needs certificate coverage. HTTP/2 also depends on a build that includes the HTTP/2 module and a TLS stack that can negotiate it with the browser.

Some choices are operational rather than syntactic. HSTS can make browsers remember HTTPS for a host and, with subdomain or preload settings, can affect names beyond the one being tested. IP allowlists depend on the client address NGINX actually sees, which may be a load balancer or another proxy unless real-IP handling is configured elsewhere. Compression, security headers, custom response headers, and cache rules may duplicate or conflict with higher-level http settings or with headers already set by the application.

A good server block draft makes the intended host policy visible before reload: which names are served, which names redirect, which ports listen, which content path or upstream receives traffic, which guards are applied, and which live checks still need to pass. The final authority is always the full loaded NGINX configuration, the filesystem, the certificate files, the upstream services, and a real request against the target host.

How to Use This Tool:

Build one host policy at a time, then compare the generated config with the route plan, directive ledger, and activation checklist before copying the file to a server.

Enter Server name as a bare hostname such as example.com or app.example.com. Leave out protocol, path, port, and wildcard syntax in the primary field; wildcard or extra aliases belong in Extra server names.
Choose Site mode. Use Static files or single-page app when NGINX serves files directly, PHP-FPM application when PHP scripts should go to FastCGI, or Reverse proxy to app server when another service handles the request.
Set www handling and TLS plan together. Redirecting apex to www or www to apex affects canonical links and certificate names, while HTTP redirect plus HTTPS server block emits both a redirect listener and an HTTPS content block.
Fill the mode-specific target. Static and PHP-FPM modes need Document root; PHP-FPM mode also needs PHP-FPM target. Reverse proxy mode needs one or more Backend URL(s); several bare origins on the same scheme create an upstream group.
Use Request routing for file-serving modes. Choose a 404 fallback for plain static assets, a single-page app fallback for client routers, or a PHP front-controller fallback for PHP applications.
Review safety controls before deployment. Access policy can emit allow/deny rules, Dotfile protection blocks hidden files except .well-known, HSTS policy affects future browser behavior, and Basic security headers should not duplicate stricter app headers.
Open Advanced for bind address, nonstandard ports, index order, static caching, dynamic gzip, gzip_static, WebSocket upgrade headers, load-balancing method, proxy timeouts, upload body size, custom response headers, log directory, comments, and install path style.
Stop when the status says Needs edits. Fix the visible alert first; common blockers include invalid hostnames, bad backend URLs, mixed multi-backend schemes, custom TLS paths that are incomplete, an empty allowlist, unsafe custom header syntax, bad client_max_body_size text, or non-absolute paths.
When the status is Ready or Review, read Request Route Plan, Directive Ledger, and Activation Checklist. Copy the NGINX Server Block only after the tables match the host policy you intended to deploy.

Interpreting Results:

The config text is a structured draft, not proof that the target server will accept it. Ready means the current inputs passed the generator's visible checks. Review means a draft exists but at least one warning needs a decision. Needs edits means the generated text should not be treated as deployable config.

How to interpret NGINX server block generator result cues
Output cue	Meaning	Follow-up
Needs edits	At least one input blocks a usable draft.	Fix the alert before copying `NGINX Server Block`.
Review	A draft exists, but warnings describe assumptions that may be wrong on the live host.	Check each warning against `Directive Ledger` and the target server.
Ready	The selected options avoided known blockers and warnings.	Run `sudo nginx -t`, reload NGINX, then test DNS, TLS, redirects, and the content response.
`Request Route Plan`	Summarizes listener, hostname match, redirect policy, handoff, guards, and verification.	Use it to catch a surprising redirect, public/private access mismatch, or wrong handoff before reading the full config.
`Directive Ledger`	Lists the important directives, values, module surface, generated size, and deployment notes.	Confirm hostnames, root path, backend URL, certificate path, logs, and warning count.
`Activation Checklist`	Turns the draft into host-specific save, enable, syntax-test, reload, DNS/TLS, and smoke-test steps.	Run the commands on the target host, not only on a workstation copy.

A common false-confidence case is a neat config that never handles traffic. Another loaded block can be the default for the same port, DNS may point elsewhere, the certificate may miss a redirect-only name, the PHP-FPM socket may not be readable, or the upstream block may sit outside the loaded http context. Treat the route and ledger tables as a review aid, then verify the running server.

Technical Details:

NGINX request handling starts with listener selection. A server block can list a bare port, a specific IP address and port, or a TLS listener. After that address-and-port match, the server_name values compete within the same listener set. If the host name does not match any block, the default server for that listener handles the request.

Location selection and content handoff happen after the virtual server has been chosen. Static and PHP-FPM configurations rely on filesystem paths, URI fallback rules, and optional regex locations. Reverse proxy configurations rely on proxy_pass, forwarded headers, timeout settings, and sometimes an upstream group that represents several backend origins.

Rule Core:

Core rule decisions for NGINX server block generation
Decision area	Draft behavior	Rule to verify
Host policy	`server_name` contains the canonical host, an optional apex or `www` companion, extra names, or redirect-only names based on the selected policy.	Served names and redirect names must match DNS, certificate coverage, application canonical-host behavior, and any wildcard intent.
Listener plan	HTTP-only, HTTPS-only, or HTTP-to-HTTPS blocks are emitted from the selected ports and bind address. HTTPS output can include `http2 on`, HSTS, and certificate paths.	The default server for the same listener can still receive unmatched requests. HTTP/2 requires a build with the HTTP/2 module and TLS negotiation support.
Static files	`root`, `index`, and `try_files` express file lookup, directory index order, and fallback behavior.	The root should point at a public directory and the fallback should match the site type: static 404, single-page app, or PHP front controller.
PHP-FPM	A PHP location passes matching scripts to `fastcgi_pass` with script filename and document root parameters.	The PHP-FPM socket or host:port must exist, be reachable, and map paths the same way the application expects.
Reverse proxy	`proxy_pass` points at a single backend URL or a generated upstream group. Forwarded headers preserve host, client IP, scheme, and forwarded-host context.	Every backend must be reachable from the NGINX host, and the app must trust forwarded fields intentionally.
Request guards	Optional allowlists, dotfile protection, body-size limits, compression, HSTS, security headers, custom headers, and logs are added at server or location level.	Guard behavior can change behind another proxy, in inherited `http` settings, or when the upstream app already sets stricter headers.

TLS certificate paths are only one part of HTTPS readiness. The files must exist, be readable by the NGINX master process, include the correct certificate chain, and cover every name that can reach an HTTPS listener. Server Name Indication lets the client name the requested host during the TLS handshake, but default-server behavior still matters when the name is missing, unsupported, or not covered by a matching block.

Upstream groups are useful when several app origins share one proxy policy. The generated group is valid only when the origins share the same scheme and do not include paths, query strings, or fragments. Path-specific routing needs a more deliberate location design than a simple multi-origin upstream list.

Directive and Review Map:

NGINX directive areas and deployment checks
Directive area	What it controls	Deployment check
`listen`	Address, port, TLS flag, and the listener set used for server selection.	Check port conflicts, IPv4 or IPv6 bind policy, and default-server order.
`server_name`	Hostnames that should match this virtual server.	Check DNS, aliases, wildcard scope, and redirect-only names.
`root` and `try_files`	Filesystem base and URI fallback behavior for file-serving modes.	Confirm the path is public, readable, and aligned with static, single-page app, or PHP routing.
`fastcgi_pass`	Where PHP requests are sent after NGINX matches a PHP script.	Confirm the PHP-FPM service, socket permissions, service port, and script path behavior.
`proxy_pass` and forwarded headers	Backend origin, upstream group, timeout behavior, WebSocket upgrade support, and request context passed to the app.	Test each backend from the NGINX host and confirm forwarded-header trust settings.
`ssl_certificate`	Certificate chain and private key for HTTPS listeners.	Check SNI, served names, redirect names, file paths, chain order, and private-key permissions.
`allow`, `deny`, `add_header`, and `gzip`	Optional access restrictions, security headers, HSTS, custom headers, and text compression.	Check real source IPs, header inheritance, browser HSTS caching, and compression policy before production use.

Validation Boundaries:

Validation and warning boundaries for NGINX server block generation
Condition	Result	Practical response
Primary host includes protocol, path, port, wildcard, or invalid characters	Blocking error	Enter a bare hostname, `localhost`, or IP address.
Reverse proxy backend is not an absolute HTTP or HTTPS URL	Blocking error	Use a backend URL reachable from the NGINX host, then test it separately.
Several reverse proxy backends use different schemes or include paths, queries, or fragments	Blocking error	Use bare origins, such as a loopback HTTP origin on port `3000`, and keep every entry on the same scheme.
Custom HTTPS is missing certificate or key path	Blocking error	Enter both absolute paths or use the derived Let's Encrypt path shape when it matches the canonical host.
Document root or log directory is not absolute	Blocking error	Use absolute paths because NGINX evaluates them on the server.
Allowlist mode has no valid source entries, or a custom response header lacks `Name: Value` syntax	Blocking error	Add at least one IP or CIDR for allowlist mode and keep custom headers to one simple header per line.
HTTP-only output, unusual document root, wildcard names, static cache, HTTP/2, HSTS preload, gzip, allowlist, custom headers, or basic security headers	Warning	Review the choice against production policy, file exposure, DNS, cache naming, app headers, and live client IP handling.

Limitations and Privacy Notes:

The draft is created from the values you enter, but it cannot inspect the running NGINX process, the target filesystem, certificate contents, DNS records, PHP-FPM status, or backend health. It also does not run nginx -t for you.

Run sudo nginx -t on the target host to catch directive, module, certificate, path, and quoting errors.
Smoke-test the canonical hostname and every redirect-only name after reload.
Confirm upstream health outside NGINX when using reverse proxy mode, and confirm PHP-FPM socket or port access when using PHP-FPM mode.
Treat hostnames, private backend URLs, allowlisted addresses, and downloaded config files as infrastructure-sensitive. Do not share a browser URL or export that contains private values unless the recipient should see them.

Advanced Tips:

Choose the canonical host before setting www handling; redirect-only names still need DNS and certificate coverage when HTTPS listeners can receive them.
Keep HTTP/2 enabled only when the target build supports the modern http2 on directive and TLS Application-Layer Protocol Negotiation.
Stage HSTS policy conservatively. Use site-only HSTS after HTTPS is stable, and reserve preload for hosts whose subdomains can remain HTTPS long term.
For several Backend URL(s), keep each entry as a bare origin on the same scheme so the upstream group belongs in a loaded http context.
Use Access policy allowlists only after confirming whether NGINX sees the real client IP or the address of a load balancer or reverse proxy.
Review Custom response headers against application headers because nested NGINX locations can change inheritance and duplicate browser policy headers.

Worked Examples:

PHP-FPM site with HTTPS redirects

For example.com, choose PHP-FPM application, Redirect www to apex, and HTTP redirect plus HTTPS server block. Keep Document root pointed at the public directory and set PHP-FPM target to the socket or service port. Directive Ledger should show server_name, the redirect-only www name, certificate paths, fastcgi_pass, and the selected module surface.

Reverse proxy to one local app

For an app listening on the same host, choose Reverse proxy to app server and set Backend URL(s) to the loopback HTTP origin on port 3000. If the app uses WebSockets, turn on WebSocket upgrade headers. Request Route Plan should show the proxy target as the content handoff, and Activation Checklist should include a backend curl -I check before reload.

Two app instances behind one hostname

In reverse proxy mode, enter the same loopback HTTP origin with ports 3000 and 3001 on separate lines. Choose least_conn when long requests make simple round-robin less useful. NGINX Server Block should include an upstream block, while Directive Ledger should show upstream / proxy_pass with both backend origins.

Static single-page app

For a client-routed app, choose static mode, set Document root to the deployed public directory, and set Request routing to the single-page app fallback. Turn on Static asset cache only when asset filenames are versioned. A cache warning in the result is a review cue, not a syntax error.

Private staging host

Set Access policy to allowlist and enter office or VPN source ranges in Allowed IPs / CIDRs. Directive Ledger should show allow / deny. If a load balancer or another proxy sits in front of NGINX, confirm NGINX sees the real client address before deploying those rules.

Custom certificate path error

If HTTPS is enabled with Custom certificate files but Private key file is blank, the status becomes Needs edits. Add the missing absolute path or switch back to the Let's Encrypt profile before using NGINX Server Block.

FAQ:

Why should the server name not include a protocol?

server_name matches hostnames, not full URLs. Put only the host in Server name, then choose TLS plan to decide whether the draft listens on HTTP, HTTPS, or both.

Why does HTTP-only output raise a warning?

HTTP-only output can be valid for local setup or certificate bootstrap work, but public production sites normally need HTTPS. The warning makes that choice deliberate before deployment.

What does an unusual document root warning mean?

The path does not end with a common public directory name such as public, htdocs, html, webroot, or www. Confirm the root will not expose private app files.

Can the draft prove the certificate is valid?

No. It can place certificate directives, but certificate coverage, SNI behavior, file permissions, chain order, and expiry must be checked on the target server.

Why does multi-backend mode reject paths?

An upstream group names backend origins, not individual URL paths. Use bare origins in Backend URL(s), then design separate locations if the app needs path-specific routing.

Should HSTS be enabled immediately?

Only after HTTPS is stable for every served and redirected name. Browsers cache HSTS, and preload mode is especially hard to reverse once submitted and widely distributed.

What should I fix first when the status says Needs edits?

Fix the visible alert before reading the draft as deployable config. Common blockers are invalid hostnames, bad backend URLs, incompatible multi-backend entries, missing custom certificate paths, empty allowlists, invalid custom headers, bad body-size syntax, or non-absolute paths.

Are private backend names safe to share?

Treat them as sensitive. The generated config, downloaded files, copied rows, and shared browser URLs may contain hostnames, backend URLs, allowlisted source addresses, and filesystem paths.

Glossary:

Server block: An NGINX virtual server definition that matches requests and defines how they are handled.
server_name: The directive that lists hostnames a server block should match.
Document root: The filesystem directory NGINX uses as the base for static or PHP file lookup.
PHP-FPM: A FastCGI service that runs PHP code for NGINX.
Reverse proxy: A server pattern where NGINX receives the client request and forwards it to an upstream application.
Upstream group: A named set of backend origins that NGINX can use behind one proxy target.
SNI: Server Name Indication, the TLS extension that lets a client name the requested host during the handshake.

References:

How nginx processes a request, NGINX.
Configuring HTTPS servers, NGINX.
NGINX Reverse Proxy, F5 NGINX.
Module ngx_http_core_module: try_files, NGINX.
Module ngx_http_fastcgi_module, NGINX.
Module ngx_http_v2_module, NGINX.
Strict-Transport-Security header, MDN Web Docs, Apr. 23, 2026.
How to enable HTTP/2 in Nginx, Simplified Guide.
How to improve Nginx security, Simplified Guide.