A working Nginx config generator example produces one auditable HTTP server block, with exact listen lines, a single server_name, an absolute document root, try_files fallbacks, bounded asset caching and optional gzip directives, that you review against the deployed Nginx version before placing it in the active configuration. The block stays intentionally narrow: it covers a small static origin, not a full production baseline. Inputs are validated so semicolons, braces and shell-like syntax cannot inject extra directives, and the generated fragment is meant to be read line by line, not pasted blindly. Each directive maps to a documented behavior in the Nginx core and gzip modules, and the limits are explicit. TLS, FastCGI, proxying, uploads, auth, rate limits and security headers are deliberately left out because they depend on deployment evidence the browser cannot see. Treating the example as a reviewable fragment, not a finished production file, is what makes it useful.
The tool's contract is straightforward. It runs entirely in the browser, accepts one exact domain, one absolute document root, an integer cache duration between 1 and 365 days, an SPA fallback toggle and a gzip toggle, then assembles a fixed HTTP block. The output stays local; nothing is uploaded. Because every input is validated and every directive is generated from a documented fixture, the example block you copy is reproducible. Running the tool with the same values produces the same text, which is what makes it auditable rather than a guess, and it is why the result pairs naturally with the Nginx core module documentation when you walk through each directive.
Two Scenarios the Generator Covers Side by Side
The generator accepts a small set of inputs and produces a block tailored to one of two shapes: a regular static site with an explicit 404, or a single-page application whose unknown paths should fall back to index.html. The table below shows how the inputs and the resulting try_files directive differ across the two scenarios.
| Field | Static site | Single-page application |
|---|---|---|
| Domain (server_name) | One exact host | One exact host |
| Document root | Absolute POSIX path | Absolute POSIX path |
| Cache duration | 1 to 365 days | 1 to 365 days |
| SPA fallback toggle | Off | On |
| Final try_files argument | =404 | /index.html |
| listen lines | 80; and [::]:80 | 80; and [::]:80 |
| Asset location extensions | CSS, JS, images, icons, WOFF2 | CSS, JS, images, icons, WOFF2 |
| Optional gzip types | CSS, JS, JSON, SVG | CSS, JS, JSON, SVG |
Both shapes share the same listen lines (IPv4 and IPv6 port 80), the same exact server_name rule, the same asset location and the same optional gzip section. The only behavioral switch is the final try_files argument, and the generator only lets you toggle it deliberately rather than inferring it from the domain. Enabling SPA fallback on a regular content site is a known footgun: returning the home shell with status 200 for missing resources can hide broken URLs and damage error semantics, so the toggle exists but is not the default behavior.
Inputs the Generator Will and Will Not Accept
The form rejects inputs that look like configuration rather than values. A domain carrying a scheme such as https:// or http:// is rejected. A document root containing semicolons, braces, whitespace, variables or any shell-like syntax is rejected. A cache duration outside the 1-to-365-day contract is rejected. The path validation does not check whether the directory exists on the target server, whether ownership matches the Nginx worker user or whether the path is readable; that information the browser cannot inspect is left as a deployment step. The generator also refuses to add a wildcard, an alternate www host or a regex server_name, because each of those choices changes virtual-host routing and certificate coverage. If several names should serve or redirect, that behavior has to be designed explicitly in the surrounding configuration rather than assumed from a single input field.
The asset location covers a small fixed list: CSS, JavaScript, common images, icons and WOFF2 fonts. The expires directive applies the chosen duration and adds Cache-Control public. If you select a long cache duration, version or fingerprint your static assets so visitors do not keep stale files after a deployment. The generator does not rewrite your filenames. The optional gzip section enables the standard filter, adds Vary: Accept-Encoding and lists CSS, JavaScript, JSON and SVG; HTML is handled by Nginx's default gzip behavior without needing to appear in gzip_types, which mirrors the behavior described in the Nginx gzip module documentation. Compression can create side-channel concerns for secrets reflected into compressed responses, and precompressed assets need a different configuration, so the toggle is documented rather than assumed.
Walking Through the Generated Example
Below is the concrete path from inputs to a copyable block. Each step is a deliberate action, and nothing is automated on the server side. Reading the example this way keeps the output reviewable instead of mysterious.
- Enter one exact domain. Type a single host such as www.example.com. Schemes, paths, wildcards and regex characters are rejected at this step. The same domain will appear verbatim in the generated server_name line; no alternate or www alias is added automatically.
- Enter an absolute document root. Use a full POSIX path such as /var/www/example.com/html. The generator accepts only bounded safe path characters; semicolons, braces, variables, whitespace and shell-like syntax cause rejection. The path still has to exist on the target server with correct ownership and read permissions, and the browser cannot verify those facts.
- Pick a cache duration. Enter an integer between 1 and 365. That value becomes the expires argument in the asset location and is paired with Cache-Control public. If you ship long-lived assets without filenames or query-string versioning, pick a shorter duration to avoid stale files after deploys.
- Choose static 404 or SPA fallback. For a normal content site leave SPA fallback off so missing paths return =404. Turn it on only when client-side routing should receive unknown application paths; in that case the final try_files argument becomes /index.html.
- Toggle gzip if appropriate. Enable it when you want compressed CSS, JavaScript, JSON and SVG responses with the Vary: Accept-Encoding header added. Leave it off when responses may include secrets that compression could expose or when assets are precompressed.
- Generate and review the block. The output is one HTTP server block listening on port 80 for IPv4 and IPv6, with one exact server_name, the chosen root, a try_files for location /, a case-insensitive asset location and the optional gzip lines. Read every line before copying.
- Place the fragment in context. Save the active configuration and record the include chain. Drop the reviewed file into the correct context inside nginx.conf or a sites-enabled include. Do not duplicate server blocks for the same name; the generator's tests assert exact block boundaries.
- Run nginx -t against the full configuration. A successful syntax test proves directives and references parse, nothing more. If it fails, fix the configuration and re-test; do not reload.
- Test representative requests. Hit the home path, a known asset, a known missing path and, if SPA fallback is on, an unknown application path. Confirm status codes, cache headers, gzip behavior and that the correct file is served. nginx -t cannot prove file permissions, DNS, application routing or certificate behavior, so this step is mandatory.
- Reload rather than stop. When the platform procedure supports a graceful reload, use it. Keep a recovery shell open. If requests fail after reload, restore the backup and inspect the error log before iterating.
For readers who want to see the actual generated text, the Nginx Config Generator runs entirely in the browser and produces exactly that block from the inputs above. The Nginx Config Generator Cheat Sheet pairs the example with the exact directives and limits referenced in each line, which makes a useful follow-up read once you have generated your first block.
Comparing the Example to a Hand-Written Server Block
A useful way to read the generated example is to contrast it with a server block written by hand for the same job. Both end with an HTTP server listening on port 80, a single server_name and a document root, and both can serve static files correctly when configured carefully. The differences show up in scope and guardrails rather than in any single line.
A hand-written block can carry wildcards, regex server names, alternate www hosts, redirects and rewrites in one place because the author has the full deployment in mind. The generated example deliberately refuses those choices because they affect virtual-host routing and certificate coverage and because the browser cannot infer ownership of multiple names from a single input field. A hand-written block can include TLS, FastCGI, proxying and security headers; the generated example omits all of them on the grounds that those directives depend on certificate paths, backend addresses and header policies that the tool cannot see. A hand-written block is shaped by the author's habits and the surrounding configuration; the generated example is constrained by a fixed set of documented fixtures so the output is reproducible from the same inputs.
The practical takeaway is that the generated example is a smaller, more predictable starting point, while a hand-written block is a larger, more context-aware artifact. Neither is a substitute for the other: the generator produces a reviewable fragment you can drop into a real configuration, and a hand-written block is appropriate when the static-site assumptions no longer hold.
What the Example Deliberately Leaves Out
The example is a static-site fragment, not a production baseline for every application. TLS is intentionally excluded: correct HTTPS depends on certificate paths, renewal tooling, supported protocols, redirects, proxy or CDN topology and HSTS policy, and inventing certificate locations would produce dangerous false confidence. HTTPS has to be configured through the hosting platform or a reviewed server procedure, then the HTTP-to-HTTPS behavior tested separately. The output also omits PHP and FastCGI, reverse proxying, WebSockets, uploads, authentication, rate limits, custom error pages, MIME include paths, logging and security headers. Each of those belongs in a separate, evidence-led decision against the actual architecture and the official Nginx module documentation.
The most maintainable result is the smallest reviewed config that matches current deployment evidence. If traffic lands on managed hosting, containers, Kubernetes ingress or a CDN, the correct configuration surface may be elsewhere, and a static-site generator block is the right starting point only when the problem really is a small static origin. When you do deploy the example, treat it as a reviewable fragment: back up the active configuration, place the file in context, run nginx -t, test representative requests and reload rather than stop. Permanent cache and routing mistakes can affect visitors even while Nginx remains online, so the testing sequence exists to surface them before real traffic does.