Nginx Cheatsheet

THE PRACTICAL GUIDE · NORMANDIN SYSTEMS

Get more from Nginx Cheatsheet

Nginx Cheatsheet summarizes common configuration concepts and commands used to inspect and manage Nginx. Configuration is organized into contexts, so a directive's location affects whether it is valid and what it controls. Server and location selection, upstream routing, and included files can all influence the response beyond the single fragment being edited. A cheatsheet works best as a memory aid while you practice a concrete task. Read the command or syntax together with its arguments, placeholders, and surrounding context. Similar-looking options can have very different meanings, and an example written for one platform or version may need adjustment elsewhere. Keep the reference beside a small test case, use read-only examples first when possible, and check the relevant help output before applying an unfamiliar command to valuable files or a running service.

Guide updated October 13, 2026

How to use this tool

1. Identify the operation you want to perform and find the matching section of the reference. Read the whole example before copying any part of it.
2. Locate the relevant directive or command, check its allowed context, and validate a draft configuration before reloading a service.
3. Review the example below and compare its expected behavior with a small sample of your own input before continuing.
4. Try the adapted example on a small test case, compare the result with the explanation, and save the command with a note about the context in which it works.

SEE IT IN PRACTICE

A worked example

nginx -t

A configuration syntax and referenced-file check using the selected Nginx setup

A successful check is useful before a reload, but it does not prove that every route or upstream behaves correctly.

Directive context controls interpretation

Nginx configuration contains nested contexts, and a directive valid in one context may be invalid or mean something different elsewhere. Included files can also contribute settings that are not visible in the fragment being edited. Review the complete effective configuration and locate the server or location that actually handles the request. A syntax test is a useful first gate, but it does not prove that location matching, upstream routing, or filesystem mapping produces the intended response.

Test requests that distinguish similar routes

When reviewing a proxy or static-file configuration, test representative paths including a trailing slash, a missing resource, and a route close to another prefix. These cases reveal matching or rewrite assumptions that a homepage request may not exercise. Check the intended host header and TLS context as well. Use a controlled reload process after syntax validation and retain a recoverable configuration. If a request fails, compare the relevant access and error information before making broad changes to unrelated directives.

When this tool is useful

• Find configuration-check syntax
• Review a reverse-proxy example
• Understand server and location context

Tips for a better result

• Review included files, server names, location behavior, and the intended configuration path, then test representative requests after a controlled change.
• Replace example paths, identifiers, and names deliberately. Copying a reference command unchanged can target a different file, branch, service, or environment from the one you intended.
• Keep the source and the settings used for this result together. That makes a later comparison or correction easier, especially when another person needs to reproduce the same outcome.

Frequently asked questions