---
title: "nginx.conf"
description: "nginx.conf: structure in contexts, server and location blocks, location matching order, testing and reloading, and useful rules for WordPress."
language: "en"
locale: "en-US"
type: "definition"
canonical: "https://www.wp-masquerade.com/glossary/nginx-conf/"
published: "2026-10-28T08:00:00+00:00"
modified: "2026-10-28T20:08:35+00:00"
translations:
  en-US: "https://www.wp-masquerade.com/glossary/nginx-conf/index.md"
  fr-FR: "https://www.wp-masquerade.com/fr/definitions/nginx-conf/index.md"
  es-ES: "https://www.wp-masquerade.com/es/glosario/nginx-conf/index.md"
  de-DE: "https://www.wp-masquerade.com/de/glossar/nginx-conf/index.md"
  it-IT: "https://www.wp-masquerade.com/it/glossario/nginx-conf/index.md"
  pt-BR: "https://www.wp-masquerade.com/pt/glossario/nginx-conf/index.md"
  nl-NL: "https://www.wp-masquerade.com/nl/woordenlijst/nginx-conf/index.md"
---

# nginx.conf

nginx.conf is the main configuration file of the Nginx web server. It's organized in nested blocks called contexts (events, http, server, location) that describe the sites served, the addresses listened on, how each path is handled and how PHP scripts are passed to PHP-FPM. For the whole server, it takes the place of Apache's .htaccess files.

Where Apache scatters its configuration across .htaccess files placed in the site's folders, [Nginx](https://www.wp-masquerade.com/glossary/nginx/) keeps it in one place. According to its documentation, the file is named nginx.conf and lives in `/etc/nginx`, `/usr/local/nginx/conf` or `/usr/local/etc/nginx`. It often includes other files, one per site, stored in `conf.d/` or `sites-available/` depending on the distribution.

## How nginx.conf is organized

The file is made up of directives. A simple directive ends with a semicolon; a block directive holds other directives between braces, and is called a context when it can contain them. Anything outside every block belongs to the main context, which contains `events` and `http`; `server` goes inside `http`, and `location` inside `server`.

![Diagram of the nested contexts of nginx.conf. The main context holds general directives such as worker_processes. The events block handles connections. The http block holds settings shared by all websites. Each server block describes a site, with listen and server_name. Each location block says how to handle a path, for example try_files for permalinks or fastcgi_pass to PHP-FPM for PHP files.](https://www.wp-masquerade.com/media/2026/10/blocs-nginx-conf-en.webp)

*Nginx configuration nests like Russian dolls: main, then http, then server, then location.*

Here are the essentials for a WordPress site, with [PHP-FPM](https://www.wp-masquerade.com/glossary/php-fpm/) listening on a socket:

```
server {
    listen 443 ssl;
    server_name example.com;
    root /var/www/example;
    index index.php;
    location / {
        try_files $uri $uri/ /index.php?$args;
    }
    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/run/php/php-fpm.sock;
    }
}
```

## The order of location blocks

This is the most common source of mistakes. According to the documentation, Nginx first looks for an exact match (`=`), which ends the search. It then remembers the longest matching prefix; if that prefix carries `^~`, it stops there. Otherwise, it tests regular expressions (`~`, case-sensitive, and `~*`, case-insensitive) in the order they appear in the file, and the first one that matches wins. Only when none matches does it fall back to the remembered prefix. In practice, a blocking rule written as a plain prefix can be bypassed by the `~ \.php$` block.

## Testing and reloading

`nginx -t` checks the syntax and access to the files it references, without applying anything. `nginx -s reload` then applies the new configuration: the master process validates it, starts new workers and shuts down the old ones once their current requests are done; if there's an error, it keeps the old configuration.

*Video: “Learn Proper NGINX Configuration Context Logic” (NGINX)*

## For WordPress

- **No plugin can edit nginx.conf**: rules a plugin would write to an [.htaccess](https://www.wp-masquerade.com/glossary/htaccess/) file have to be carried over by hand or by the host.
- **Block sensitive files** with exact or regular-expression locations placed before the PHP block: backups, .git, .env, debug.log, as in our article on exposed files.
- **Restrict the admin area** by IP or HTTP authentication, following our guide to protect wp-admin on the server side.
- **WP Masquerade** only needs nginx.conf for the Pro version's file aliases, for which it displays the block to copy into the server block, and for one line that hides its folder: the [hosting and cache compatibility](https://www.wp-masquerade.com/features/hosting-and-cache-compatibility/) page gives these rules. Test with `nginx -t` before reloading.

## Related terms

- [Nginx](https://www.wp-masquerade.com/glossary/nginx/)
- [htaccess file (.htaccess)](https://www.wp-masquerade.com/glossary/htaccess/)
- [PHP-FPM](https://www.wp-masquerade.com/glossary/php-fpm/)
- [Apache HTTP Server](https://www.wp-masquerade.com/glossary/apache-http-server/)
- [HTTP/2 and HTTP/3](https://www.wp-masquerade.com/glossary/http2-http3/)


## Sources

- [nginx : Beginner’s Guide](https://nginx.org/en/docs/beginners_guide.html)
- [nginx : Module ngx_http_core_module (location)](https://nginx.org/en/docs/http/ngx_http_core_module.html#location)
- [nginx : Command-line parameters](https://nginx.org/en/docs/switches.html)
- [WordPress Advanced Administration : Nginx](https://developer.wordpress.org/advanced-administration/server/web-server/nginx/)