Hey there! Let's unpack each of your Nginx config files, their use cases, how they load, and what happens when directives overlap—this stuff can feel tangled at first, but it's straightforward once you map it out.

Individual File Breakdowns #

/etc/nginx/nginx.conf #

This is your core master configuration file—think of it as the foundation for all Nginx settings. It defines global-level directives that apply to the entire server, like:

• Number of worker processes (worker_processes)
• Paths to error logs and PID files (error_log, pid)
• Global connection limits (keepalive_timeout)
• Include statements that tell Nginx where to find other config files

Use case: Any setting that affects Nginx's overall performance or global behavior. You’ll rarely put site-specific rules here; save those for the other files.

/var/etc/nginx/sites-available/myproject #

This is a site-specific configuration file, designed to hold rules for a single project or domain (like a virtual host). It’ll typically contain one or more server blocks defining:

• Domain names (server_name)
• Root directory for your web files (root)
• Proxy rules for backend apps (proxy_pass)
• SSL settings

Important note: Files in sites-available aren’t loaded by Nginx automatically. You need to create a symbolic link from this file to the sites-enabled directory (e.g., ln -s /var/etc/nginx/sites-available/myproject /var/etc/nginx/sites-enabled/) for Nginx to pick it up.

Use case: Managing separate configurations for different websites or services on the same server. It keeps your setup clean and makes it easy to enable/disable sites by adding/removing the symlink.

/etc/nginx/conf.d/default.conf #

Files in the conf.d directory are auto-loaded configuration snippets (assuming your nginx.conf includes a line like include /etc/nginx/conf.d/*.conf;). This default file usually holds the default server block—think the page you see when you visit your server’s IP without a specific domain.

Use case: Quick, generic configurations that don’t need the separate sites-available/sites-enabled workflow. You might also use conf.d for shared rules (like global redirects) that apply to all sites.

/etc/nginx/conf.d/web_conf #

This works exactly like default.conf, but with a custom filename. One catch: if your nginx.conf uses include /etc/nginx/conf.d/*.conf; (the standard setup), Nginx won’t load this file because it doesn’t have the .conf extension. To fix this, you’d either rename it to web_conf.conf or update the include line to include /etc/nginx/conf.d/*; (to load all files in the directory, regardless of extension).

Use case: Same as conf.d/default.conf—custom snippets for shared rules, additional server blocks, or upstream definitions (like backend server pools).

Loading Order #

Nginx loads configs in this sequence:

1. First, it reads the entire /etc/nginx/nginx.conf file.
2. Then, it processes any include statements in nginx.conf in the order they appear. For example:
   • If nginx.conf has include /etc/nginx/conf.d/*.conf; first, it’ll load all .conf files in conf.d (sorted alphabetically by filename) before moving to include /var/etc/nginx/sites-enabled/*;.
   • If the include lines are reversed, sites-enabled files load first.

Remember: The sites-available files only load if they’re symlinked to sites-enabled and included via nginx.conf.

Directive Override Rules #

This depends on the type of directive and where it’s defined:

• Global directives (main context): These can only be set once in nginx.conf (or included files in the main context). If you try to redefine them later (e.g., in a server block or conf.d file), Nginx will throw an error. Examples: worker_processes, error_log.
• Server block directives: If multiple server blocks match a request (e.g., two blocks listening on port 80), Nginx uses priority rules to pick which one to use:
  1. Exact server_name matches (e.g., server_name example.com; beats server_name *.example.com;).
  2. If no exact match, the first defined server block with a wildcard or regex match.
  3. If no matches at all, the default server block (marked with default_server in the listen directive, or the first server block loaded if none is marked).
• Same-context directives: If you define the same directive twice in the same context (e.g., two root lines in one server block), the last one overrides the first.

内容的提问来源于stack exchange，提问作者user3541631