An nginx config generator is a narrow tool that converts a small set of validated inputs, including one exact domain, a safe absolute document root, a cache duration in days, and a static-404 or SPA-fallback decision, into a single HTTP server block intended for review inside a larger Nginx installation. The generator described here is explicitly bounded: it listens on port 80 for IPv4 and IPv6, selects one server_name, and rejects wildcards, alternate www hosts, and regex names because those choices change virtual-host routing and certificate coverage. It does not invent TLS, certificate paths, redirects, or proxy topology, because each of those requires deployment-specific evidence the browser cannot inspect. The output stays local in the browser and is meant to be read line by line against the official module documentation before it is placed into the active include chain, tested with nginx -t, and exercised with representative requests. Try the Nginx Config Generator to do this in your browser.
What the generator actually outputs
The tool builds one server block and only one server block. The block contains exactly the directives needed for a plain static site or a single-page application: a listen directive for port 80 on both IPv4 and IPv6, one exact server_name, an absolute root, an index line, a try_files fallback, an asset location with an expires duration, and optional gzip lines. It does not add a server-level access_log, error_log, or include directive, because those paths depend on the host's logging policy and the distribution's snippet layout. It does not insert PHP, FastCGI, WebSocket, or reverse-proxy rules, because those features point at application backends the generator cannot see. The contract is intentionally small: a fragment you review, not a production baseline for every kind of application.
How input is validated and bounded
The form accepts only what it can guarantee to use safely. The domain field accepts a plain hostname and rejects scheme prefixes; the document root must be an absolute POSIX path built from bounded safe characters, with semicolons, braces, variables, whitespace, and shell-like syntax rejected so user input cannot smuggle additional directives into the block. The cache duration must be an integer between 1 and 365 days. Each choice is tested against negative cases before assembly, and the final block is asserted against exact boundaries so duplicated server blocks cannot pass. The browser cannot confirm that the path exists on the target server with the right ownership and read permissions; that remains a deployment check outside the form.
| Input field | Accepted form | Rejected |
|---|---|---|
| Domain | One plain hostname | Scheme prefix, port suffix, wildcard, regex |
| Document root | Absolute POSIX path, safe characters | Semicolons, braces, variables, whitespace |
| Cache duration | Integer 1-365 | Zero, negative, non-integer, fractional |
| Fallback choice | Static 404 or SPA (/index.html) | Inferred from domain, hybrid default |
These rules matter because every line in a server block is interpreted by Nginx. A stray semicolon or a stray variable can turn a static fragment into a directive that does something the author never intended. Keeping the parser surface narrow is what makes the output auditable in a single screen.
Static 404 versus SPA fallback
The fallback choice is the single most consequential decision in the form. For an ordinary static site, location / uses try_files with the requested URI, a directory form, and an explicit 404 fallback, so a missing file returns a real 404 status and the visitor sees an honest error page. For a single-page application, the final fallback becomes /index.html, which lets client-side routers receive unknown application paths and resolve them in JavaScript. The contract warns clearly: do not enable SPA fallback for a normal content site, because returning the home shell with status 200 for missing resources can hide broken URLs and distort error semantics. The choice is a deliberate one, not a default the generator can infer from a domain name.
How to build and test the block step by step
- Enter one exact domain, a safe absolute document root, a cache duration in days, and choose static 404 or SPA fallback deliberately. Decide the fallback before you generate, not after.
- Generate the block and read every directive against the installed Nginx modules, your distribution's deployment paths, and your cache strategy. Version or fingerprint long-lived assets if you intend to set a high duration.
- Back up the active configuration, record the active include chain, and place the reviewed fragment into the correct context inside that chain. Run nginx -t against the full configuration.
- Test representative requests against the running service (home page, a static asset, a deliberately missing path, and the SPA route if enabled) before you reload. Reload rather than abruptly stopping the service when the platform procedure supports it, and keep a recovery shell open.
Each step has a specific failure mode if it is skipped. Skipping the fallback decision leaves a site that may return 200 for paths that should return 404. Skipping the directive review leaves a block that compiles but conflicts with modules you have not loaded. Skipping the backup leaves no rollback when the reload misroutes traffic.
Cache duration and gzip choices
The asset location is case-insensitive and covers a small fixed extension list: CSS, JavaScript, common images, icons, and WOFF2 fonts. The expires directive uses the selected 1-to-365-day duration and Cache-Control public is added. This is the right place to think about version or fingerprint long-lived assets before selecting a high duration; otherwise visitors may keep stale files after a deployment. Optional gzip turns on the standard filter, adds Vary: Accept-Encoding, and lists CSS, JavaScript, JSON, and SVG types, in line with the Nginx gzip module documentation. HTML is handled by Nginx's own gzip behavior without needing to appear in gzip_types. The generator also notes that compression can create side-channel concerns for secrets reflected into compressed responses, and that precompressed assets need different configuration. Real measurement of the live site and security context belongs in your review.
Where the tool deliberately stops
The output also omits TLS, PHP, FastCGI, reverse proxying, WebSockets, uploads, authentication, rate limits, custom errors, MIME include paths, logging, and security headers. This is not a gap to fill by guessing. HTTPS depends on certificate paths, renewal tooling, supported protocols, redirects, proxy or CDN topology, and HSTS policy. Inventing certificate locations would produce dangerous false confidence. Configure HTTPS through the hosting platform or a reviewed server procedure, then test HTTP-to-HTTPS behavior separately. Use the generator when the problem really is a small static origin. For managed hosting, containers, Kubernetes ingress, or a CDN, the correct configuration surface may be elsewhere, and forcing a static-site fragment into those environments can hide real differences in how requests are routed. Readers migrating from Apache can pair the generator with a separate, deliberately narrow htaccess to nginx conversion tool rather than asking one form to do both jobs.
What nginx -t proves and what it does not
nginx -t validates syntax and verifies that referenced files, includes, and modules are reachable. It does not prove file permissions on the document root, DNS resolution of the domain, application-layer routing inside an SPA, certificate behavior, or the real response headers a visitor will see. That is why the workflow pairs the syntax test with representative request tests: one for the home page, one for a cached asset, one for a missing path, and one for the SPA route if fallback is enabled. If the syntax test fails, do not reload. If requests fail after reload, restore the backup and inspect error logs. Permanent cache and routing mistakes can affect visitors even when Nginx itself remains online, so the smallest reviewed config that matches current deployment evidence is the most maintainable result.