Nginx Variable Reference

Nginx exposes dozens of embedded variables that carry information about each request, the client, the connection and the upstream server. They power rewrites, header manipulation, logging and access control, yet their exact meaning and context are easy to forget. The Nginx Variable Reference is a client-side lookup tool: type a variable such as $host or $remote_addr and get a plain-English description, the context where it is valid, and a copy-ready example. Nothing is sent to a server - the entire glossary lives in your browser.

At the heart of the configuration are a handful of directives. Request variables variables such as $request_uri, $uri and $args describe the incoming request URI and query string. Client variables variables such as $remote_addr and $http_user_agent describe the connecting client and its headers. Server variables variables such as $server_name, $server_addr and $server_port describe the matching virtual server. Upstream variables variables such as $upstream_addr and $upstream_response_time describe the proxied backend interaction. Header variables variables such as $host, $content_type and $cookie_ expose request headers and cookies by name. Time and log variables variables such as $time_iso8601, $request_time and $status support structured logging and analysis. Proxy variables variables such as $proxy_host and $proxy_add_x_forwarded_for simplify passing data to backends. Argument variables variables such as $arg_ and $cookie_ give per-name access to query parameters and cookies. Together they shape how the server behaves, and the tool assembles them in the right context so the result is valid on the first try.

Common mistakes are easy to make. Forgetting the leading dollar sign is harmless because the tool strips it, but in real config the dollar sign is required. Assuming $host always equals the raw Host header is wrong; $host falls back to server_name when the header is missing. Using $request_uri in a rewrite can cause redirect loops because it keeps the original arguments and path. Reading $upstream_response_time on a cache hit may be empty since no upstream call was made. The generator anticipates each of these and either sets a safe default or rejects the input with a clear message before anything is written to your clipboard.

Validation is strict because small configuration errors fail in subtle ways. Every input is checked for plausibility, and after the block is assembled it is re-parsed by a built-in tokenizer so unbalanced braces, missing semicolons or stray characters cannot reach your clipboard. Stat cards report line and block counts, and copy, download and print exports are one click away. Everything runs in your browser; nothing you type is transmitted to any server.

In practice this block drops into any standard nginx install. Save the output as a file under /etc/nginx/conf.d/ (or sites-available with a symlink), run nginx -t to confirm the syntax, then reload with nginx -s reload. Because the generator emits a single, self-contained server block with no hidden dependencies, it composes cleanly with your existing caching, logging and security configuration without directive collisions.

Beyond producing correct config, the tool is a reference you can read back and learn from. Each control maps to a real nginx directive, the sample button shows a complete working block in seconds, and clearing the form resets every field to its safe default. Standardising on a generator like this removes per-developer variation, keeps your configuration readable, and gives you a repeatable, auditable setup that passes nginx -t on the first try.

When something looks wrong in production, the first move is always to re-run nginx -t and inspect /var/log/nginx/error.log; most failures surface there with a line number. The access log records every request, so a sudden spike or a wall of 499 responses points straight at backend or timeout problems the generator helps you avoid in the first place.

This server block is designed to sit alongside - not fight - your other configuration. Because it declares its own server_name and a single, self-contained set of directives, you can drop it into conf.d without worrying about collisions with global caching, logging or security snippets that live elsewhere in the nginx tree.

For a production site, pair this block with TLS termination: serve on 80 for the redirect or health checks, and place the encrypted listener (or a front-end load balancer / CDN) in front so clients always speak HTTPS. The generator keeps that boundary clean so the two layers compose instead of overlapping.

If a change ever needs to be undone, the output is plain text you control: delete the file from conf.d, re-run nginx -t, and reload. There is no database and no hidden state, so rolling back is as simple as restoring the previous version from version control or your own backup.

• Request variables - variables such as $request_uri, $uri and $args describe the incoming request URI and query string.
• Client variables - variables such as $remote_addr and $http_user_agent describe the connecting client and its headers.
• Server variables - variables such as $server_name, $server_addr and $server_port describe the matching virtual server.
• Upstream variables - variables such as $upstream_addr and $upstream_response_time describe the proxied backend interaction.
• Header variables - variables such as $host, $content_type and $cookie_ expose request headers and cookies by name.
• Time and log variables - variables such as $time_iso8601, $request_time and $status support structured logging and analysis.
• Proxy variables - variables such as $proxy_host and $proxy_add_x_forwarded_for simplify passing data to backends.
• Argument variables - variables such as $arg_ and $cookie_ give per-name access to query parameters and cookies.
• Self-verifying output re-parsed before display.
• Copy, Download and Print exports.
• Load-sample button fills realistic values.
• Statistics cards for quick checks.
• Runs entirely in your browser - nothing uploaded.

1. Type a variable name into the search box (with or without the $ sign).
2. Click Look up (or Load sample to prefill $host).
3. Read the description, context and example in the report.
4. If several variables match, a list of candidates is shown with summaries.
5. Click Download to save the text report or Download JSON for structured data.
6. Copy the example line directly into your own configuration.
7. Clear the box to reset and look up another variable.

Example 1 - Look up $host typing $host returns its description, http/server/location context and a proxy_set_header example.

Example 2 - Look up without the dollar typing remote_addr works exactly like $remote_addr because the sign is optional.

Example 3 - Partial match typing addr lists every variable whose name contains addr, such as remote_addr and server_addr.

Example 4 - Empty query submitting an empty box returns a clear error asking for a variable name.

Example 5 - Unknown variable typing a made-up name returns an error indicating no variable was found.

• Instant, offline lookup of every common Nginx variable.
• Plain-English descriptions paired with real config examples.
• Context field tells you exactly where the variable is valid.
• Partial matching helps when you only half remember a name.
• One-click JSON and text export for docs or snippets.
• Private: the glossary is built into the page, nothing uploaded.