Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A server block is configuration; a .conf file is just a file that may contain it. NGINX reads a root configuration tree, usually starting at nginx.conf. An include directive loads other files into a specific context. A server { ... } block inside the HTTP context defines a virtual server, while a filename such as example.com.conf has no routing effect until an active include statement loads it.
This distinction explains most NGINX layout questions: where to put listen and server_name, whether every website needs its own file, and why a perfectly written configuration can appear to be ignored.
If you are deploying NGINX on a Linux VPS, Antihost VPS offers self-managed VPS plans with full root access, NVMe storage, and unlimited traffic on a 1 Gbps port in the USA East, Netherlands, and Ukraine.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →What an NGINX configuration file actually is
NGINX configuration is a text-based tree of directives and nested blocks. The main file is commonly named nginx.conf, but its location depends on how NGINX was built and packaged. Run nginx -V and inspect the compiled --conf-path value to identify the main configuration path used by the installed binary.
#1 Best Overall
The main file establishes process-wide settings and top-level contexts. Typical examples include the worker account, worker-process behavior, event handling, HTTP settings, access logging, and optional mail or stream contexts. It can then load feature-specific files with include.
The extension is not an instruction to NGINX. A file ending in .conf is ordinary text until an include directive names it directly or matches it with a wildcard. A file can contain one server block, several server blocks, or directives intended for another valid context. The parser cares about where the file is included, not what the file is called.
What a server block does
A server block is a server { ... } context in the configuration tree. When it appears inside http { ... }, it describes an HTTP virtual server: the address and port it accepts, the hostnames it serves, the document root, locations, proxy behavior, and response rules.
One server block can serve several names, and one configuration file can hold several server blocks. Conversely, a single site file is not required for each domain; separate files are an organizational choice that usually makes ownership, review, rollback, and troubleshooting easier.
The block becomes active only if the file containing it is reached from the main configuration through an include chain. Creating /etc/nginx/conf.d/example.com.conf does nothing when the active nginx.conf never includes that directory, or when the filename does not match the include pattern.
How the configuration tree is assembled
NGINX parses an included file at the point where the include directive appears. That placement determines which directives are legal. A server block included inside http is valid for HTTP virtual hosting; placing an HTTP-only directive at an incompatible level causes a configuration error.
A minimal arrangement can look like this:
# /etc/nginx/nginx.conf
user nginx;
worker_processes auto;
events {}
http {
include mime.types;
include /etc/nginx/conf.d/*.conf;
access_log /var/log/nginx/access.log;
server {
listen 80 default_server;
server_name _;
return 444;
}
}The wildcard include loads every matching file in that directory into the surrounding http context. The default server shown above is therefore at the same logical level as any site blocks loaded by the wildcard.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
A site file can then contain only the block needed for that site:
# /etc/nginx/conf.d/example.com.conf
server {
listen 80;
server_name example.com www.example.com;
root /var/www/example.com;
location / {
try_files $uri $uri/ =404;
}
}The two files are not competing configuration systems. The first establishes the include path and global HTTP context; the second contributes a server block to that context.
Context determines validity
NGINX documentation describes main, events, HTTP, mail, and stream contexts. Directives are valid only in the contexts they support. Settings inherited from a parent context can apply to child contexts, but inheritance does not make every directive legal everywhere.
For example, a process-level declaration belongs in the main context, event-loop settings belong in events, and an HTTP virtual server belongs in http. If an included snippet contains directives intended for a different context, moving the file or changing the include location may be necessary; changing its extension will not fix the problem.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallHow NGINX chooses a server for a request
Routing happens in stages. First, listen defines the socket candidate set: an IP address and port, or a UNIX socket. Only server blocks listening on the relevant socket are considered together.
Within that candidate set, NGINX compares the request name with server_name. Exact names, wildcard names, and regular expressions are supported, with documented priority rules. A block listening on port 80 is not selected merely because its file is named after the requested domain; the request must match the listening socket and the name rules.
What listen controls
The listen directive identifies the local endpoint. Common HTTP examples use port 80 for plain HTTP, but the essential point is that the address and port form the first selection boundary. If two blocks do not share a socket, their server_name values are not compared against each other for that request.
What server_name controls
server_name lists the names a block should answer for, such as example.com and www.example.com. Name matching is performed only after the request has entered the relevant listen group. Wildcards and regular expressions can broaden matching, but they still participate in NGINX’s defined precedence rules.
Recommended Free Tools
The role of default_server
default_server marks the fallback for a particular address-and-port combination. It receives requests that do not match another server name on that socket. If no block is explicitly marked, the first listed matching server becomes the default.
This is why a request sent to an unrecognized hostname can appear to reach the wrong website: it is being handled by the socket’s default, not by a file whose name resembles the hostname. An explicit default block can instead reject or safely handle unmatched traffic.
HTTPS selection
For HTTPS, server selection can begin with the TLS Server Name Indication (SNI) value and then be refined using the request line or Host header. A certificate and the later HTTP routing decision therefore depend on the listen socket and the names configured in the relevant server blocks.
Should every website have its own NGINX file?
No rule requires one file per website. The practical choice is an ownership and change-management decision.
| Layout | Scope | Loading mechanism | Useful when | Routing effect |
|---|---|---|---|---|
Main nginx.conf |
Process-wide and top-level contexts | Read as the root configuration | Worker, event, HTTP-wide, logging, and include declarations belong together | Establishes contexts and can define a default or other server blocks |
| One included site file | Usually one application or site | Loaded by an active include |
Independent review, rollback, and ownership boundaries matter | Contributes one or more virtual servers |
| Several site blocks in one file | A group of related virtual servers | Loaded by the same include | Related names or environments are maintained together | Each block still participates separately in socket and name matching |
| Shared snippet | Reusable directives for a permitted context | Included from the context that accepts those directives | Common rules should be maintained once | Only affects servers or contexts that include it |
Separate files generally make it easier to see which change belongs to which site, disable one application without editing unrelated blocks, and review a rollback. A combined file can be reasonable for a small installation or a tightly coupled group, provided the include context remains clear.
Distribution conventions: conf.d versus sites directories
Package layouts differ. Many Debian and Ubuntu installations expose sites-available and sites-enabled; other packages emphasize conf.d. Neither directory name has universal meaning. The active include lines in the installed nginx.conf decide what NGINX reads.
A file in sites-available is commonly treated as a stored definition, while a corresponding entry in sites-enabled is intended to be loaded. That convention works only when the distribution’s main file includes the enabled directory. On a system using include /etc/nginx/conf.d/*.conf;, a file placed elsewhere will not be discovered unless another included file points to it.
Before adopting a tutorial’s directory layout, inspect your own include statements. Copying a path convention from a different package can create an apparently valid file that is never parsed.
Safe workflow for adding or changing a site
- Find the active root file. Run
nginx -Vand identify the compiled--conf-path. Open that file and locate every relevantincludedirective, including wildcard paths. - Choose a loaded location. Add or edit the site file under an include path that is actually active. Keep process-wide directives in the main file and put the site’s
serverblock in an HTTP-compatible include. - Check the context. Confirm that every directive in the new file is legal where it is included. A file included inside
httpcan contribute HTTP server configuration; it cannot be treated as a free-floating global file. - Test before applying. Run
nginx -t. Do not reload after a failed syntax check. Correct missing semicolons, unmatched braces, duplicate or conflicting listen declarations, invalid directive placement, and path errors reported by the test. - Reload NGINX. After a successful test, reload the service using the control method provided by your operating system or installation. A reload adopts the new configuration while allowing current requests to continue rather than forcing an interruption.
- Verify both matches and misses. Send requests using each intended hostname and port. Also test an unmatched hostname on the same socket so you know which default server handles it.
Why a .conf file appears to be ignored
The directory is not included
The most common cause is a path mismatch. Check the active root file for an include that names the directory. A file can exist, have correct syntax, and still have no effect if no include reaches it.
The filename does not match the pattern
With include /etc/nginx/conf.d/*.conf;, only files matching that pattern are loaded. A backup suffix, different extension, or nested subdirectory may fall outside the match. Rename the file or adjust the include deliberately, then run nginx -t.
The file is included in the wrong context
An include inherits the context where it appears. A snippet intended for http cannot necessarily be included at main level, and a stream-oriented directive does not become valid merely because it is stored in a file ending in .conf. Move the include to a compatible parent or split the snippet by context.
Another server wins the match
If the file is loaded but requests still reach another site, inspect the complete set of blocks sharing the same listen socket. Check the spelling of server_name, wildcard scope, and whether an explicit default_server or first-listed block is handling unmatched names.
The change was never reloaded
Editing a file changes disk contents, not the running worker configuration. A successful nginx -t must be followed by a reload before the running service adopts the change.
Best Value
HTTPS selects a different block than HTTP
Compare the HTTPS listen endpoint and names separately from the port-80 configuration. TLS SNI can select a server before the HTTP request is processed, so a certificate or name mismatch can make an HTTPS test appear to bypass the intended block.
How to organize global settings, sites, and snippets
Keep global behavior centralized
Worker settings, event configuration, top-level context declarations, and HTTP-wide logging are easier to reason about in the root file. Centralizing them avoids copying process-wide behavior into every site definition.
Give applications clear ownership boundaries
Use separate included files when different people, deployment jobs, or rollback schedules manage different applications. A reviewer can then inspect one site’s listeners, names, root, locations, and fallback behavior without scanning unrelated blocks.
Make shared snippets context-specific
Reusable files are useful for directives that are valid in the context where they are included. Name or document snippets by their intended context so they are not accidentally inserted into main, events, http, mail, or stream at the wrong level.
Keep the default explicit
Define an intentional default server for each important socket when unmatched traffic must be rejected, redirected, or handled separately. Otherwise, the first matching block becomes the fallback, which can change when files or block order change.
A practical inspection checklist
- Record the
--conf-pathreported bynginx -V. - Trace each
includefrom the root file and confirm the site file’s path and filename match. - Identify the parent context for every included snippet.
- For each virtual server, write down its
listenendpoint and everyserver_name. - Mark which block is
default_server, or determine which block is first for that socket. - Run
nginx -tafter edits and resolve every reported error. - Reload only after the test passes.
- Test a known hostname, an alternate name such as
wwwwhen configured, the correct port, and an unmatched hostname.
Once these relationships are explicit, the filename becomes an organizational detail rather than a mystery. The active include chain determines whether the text is read, the context determines whether it is valid, and the combination of listen, server_name, and default-server rules determines which loaded block answers a request.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minute
