This cheat sheet covers the Nginx Config Generator's exact inputs, validation rules, generated server block directives, and the limits that decide when the tool is the right choice for a small static origin. The generator assembles one narrow HTTP server block for a single domain on IPv4 and IPv6 port 80 with a fixed server_name, an absolute POSIX document root, and optional SPA fallback, asset caching and gzip, all assembled locally in the browser without sending configuration data to a server. Use it as a quick reference when you need to remember which directives are emitted, which values are rejected, and what the tool intentionally leaves out so you can complete the rest of the server setup from reviewed documentation rather than guessing. Every line below maps back to the generator's contract or to the Nginx core and gzip module documentation, so the reference stays honest about what is configurable versus what must be added outside the tool.
What This Cheat Sheet Covers
The reference is scoped to the static-site path that the generator actually supports: one domain, one document root, one server block on port 80, and a small fixed set of cache and compression choices. It is a quick lookup for readers who already know what an Nginx server block looks like and want a fast way to confirm which values the tool accepts, which directives it emits, and which behaviors it will not infer. It is not a tutorial for configuring Nginx in general, and it is not a substitute for reading the Nginx core module documentation when the deployment needs directives that the generator does not produce.
Two things make this cheat sheet different from a generic Nginx reference. First, the generator's contract restricts inputs on purpose, so the cheat sheet lists the rejection rules alongside the accepted values. Second, the tool deliberately omits whole categories such as TLS, PHP-FastCGI, reverse proxying and security headers, so the cheat sheet spells out those omissions to prevent readers from assuming the output is a complete production baseline.
Inputs and Validation Rules
Every input field has a defined type and a defined rejection rule. Treat the table below as the authoritative checklist for what can and cannot be entered into the form before a block is generated.
| Input | Accepted Type | Validation Rule |
|---|---|---|
| Domain (server_name) | Plain hostname string | One exact name only; no wildcard, no regex, no scheme prefix, no alternate www host. |
| Document root | Absolute POSIX path | Must start with / and use bounded safe path characters; semicolons, braces, variables, whitespace and shell-like syntax are rejected so user input cannot create extra directives. |
| Cache duration | Integer days | Range 1 to 365 inclusive; values outside that range are rejected. |
| Fallback mode | Static 404 or SPA fallback | Chosen deliberately; switching changes the final try_files argument. |
| gzip | Toggle | Optional; when on, the standard gzip filter, Vary: Accept-Encoding and a fixed gzip_types list are emitted. |
The path still has to exist on the target server with correct ownership and read permissions; the browser cannot inspect those facts, so the tool does not claim the root is reachable.
How to Run the Generator Step by Step
Run the Nginx Config Generator with these concrete steps, in this order, so the output maps cleanly onto a reviewed deployment:
- Enter one exact domain, a safe absolute document root, a cache duration in days, and a deliberate choice between static 404 and SPA fallback; leave gzip off unless the asset mix justifies it.
- Generate the block and read every emitted directive line by line, comparing each one to the installed Nginx modules, the deployment's include chain, and the chosen cache strategy before saving the file.
- Back up the active configuration and record the current include chain so the change is recoverable, then place the reviewed fragment in the correct context such as a server block fragment inside an enabled site.
- Run nginx -t against the full configuration; a passing syntax test proves directive structure and references but nothing else, so do not reload on a failure and never skip the test.
- Reload through the platform's supported procedure rather than abruptly stopping the service, keep a recovery shell open, and request representative paths for static files, cached assets, and the chosen fallback behavior.
Server Block Directive Reference
The generator produces a fixed set of directives inside one HTTP server block. The table below is the complete list of what the output contains; any directive you need that is not on this list must be added separately from reviewed documentation.
| Directive | Purpose in the Generated Block |
|---|---|
| listen | IPv4 and IPv6 port 80, the only listen form the generator emits. |
| server_name | One exact hostname taken from the validated domain field; no alternate www or wildcard. |
| root | The validated absolute document root for static file serving. |
| index | The default index file used when a directory is requested. |
| location / | try_files chain with the requested URI, a directory form, and a final fallback that is either a static 404 or /index.html for SPA mode. |
| location ~* for assets | Case-insensitive match on a fixed extension list covering CSS, JavaScript, common image formats, icon files and WOFF2 fonts. |
| expires | Selected cache duration expressed as days, applied inside the asset location. |
| Cache-Control | Adds public in the asset location so intermediaries can cache the response. |
| gzip, gzip_types, gzip_vary | Standard filter, fixed type list and Vary: Accept-Encoding, emitted only when the gzip toggle is on. |
The block boundaries are asserted by the tool's tests so a duplicated server block with the same listen and server_name cannot pass, which keeps the output predictable when it lands in an existing include chain.
Static Fallback vs SPA Fallback
The fallback choice changes only the last argument of the try_files chain in location /, but the operational consequences are significant and easy to get backwards. For an ordinary static site the chain ends with a real 404 fallback, so missing resources return a true not-found response and broken URLs stay visible in error monitoring. For a single-page application the chain ends with /index.html, so client-side routing can take over for unknown application paths and serve the application shell.
Do not enable SPA fallback for a normal content site: returning the home shell with status 200 for missing resources hides broken URLs, weakens error semantics, and can confuse crawlers and uptime checks. Conversely, do not leave a static 404 in place for a SPA that relies on history-based routing, because visitors and crawlers will see a hard 404 for every deep link that the client router would otherwise handle. The decision must be deliberate and must match how the application actually behaves on the target server.
Cache Duration and gzip Settings
The expires directive inside the asset location uses the selected 1-to-365-day duration, and Cache-Control public is added so intermediaries can store the response. Pick the longest duration that still allows versioned or fingerprinted assets to be revalidated safely after a deployment; otherwise visitors keep stale files after a release, and forced reloads become routine.
Optional gzip enables the standard filter, adds Vary: Accept-Encoding, and lists CSS, JavaScript, JSON and SVG in gzip_types. HTML is handled by Nginx's gzip behavior without needing to appear in the type list, and the tool intentionally does not add other text types or precompressed variants. Compression can create side-channel concerns for secrets reflected into compressed responses, and precompressed assets need different configuration, so measure the real site and security context rather than assuming a toggle is universally safe.
What the Generator Deliberately Omits
The output omits a long list of capabilities that other Nginx tools often claim to generate, and those omissions are part of the contract rather than oversights. TLS is excluded because certificate paths, renewal tooling, supported protocols, redirects, proxy or CDN topology and HSTS policy depend on deployment-specific evidence; inventing certificate locations would produce dangerous false confidence. PHP, FastCGI, reverse proxying, WebSockets, uploads, authentication, rate limits, custom error pages, MIME include paths, logging and security headers are likewise absent. The result is a static-site fragment, not a production baseline for every application, so add only directives required by the actual architecture and official module documentation after the block is generated.
Use the generator only when the problem really is a small static origin. For managed hosting, containers, Kubernetes ingress or a CDN the correct configuration surface may live elsewhere, and the most maintainable result is usually the smallest reviewed configuration that matches current deployment evidence.
Testing the Generated Block Before Reload
A passing nginx -t proves that directives are syntactically valid and that referenced files and includes resolve, but it cannot confirm file ownership, read permissions, DNS resolution, application routing, certificate behavior or cached response headers. After the syntax test passes, request representative paths for an HTML page, a cached asset, a missing URL that should trigger the chosen fallback, and any path the SPA router would intercept in SPA mode. Compare the response status, content type, cache headers and gzip header against the generator's stated behavior, and inspect error logs for permission or path mismatches that the syntax test cannot catch.
Reload through the platform's supported procedure rather than abruptly stopping Nginx, keep a recovery shell open, and restore the backup immediately if requests fail after the reload. Permanent cache and routing mistakes can affect visitors even when Nginx stays online, so the only safe sequence is backup, place in context, syntax test, representative request, then reload. For the broader deployment flow that pairs this reference with file permissions and reload steps, the static-site Nginx config guide walks through the surrounding procedure. The gzip module reference remains the source of truth for any compression behavior the generator does not expose.