Separate config files per site in Nginx - Step-by-Step Execution

Process Flow - Separate config files per site

Create separate config files

↓

Place files in sites-available

↓

Link files to sites-enabled

↓

Reload nginx to apply

↓

Requests routed to correct site config

This flow shows how nginx uses separate config files for each site by placing them in sites-available, linking to sites-enabled, and reloading nginx to apply.

Execution Sample

Nginx

sudo nano /etc/nginx/sites-available/site1.conf
sudo ln -s /etc/nginx/sites-available/site1.conf /etc/nginx/sites-enabled/site1.conf
sudo nginx -t
sudo systemctl reload nginx

Create a config file for site1, link it to enable, test config, and reload nginx to apply changes.

Process Table

Step	Action	Command/Config	Result/Output
1	Create site1 config file	sudo nano /etc/nginx/sites-available/site1.conf	File created with server block for site1
2	Enable site1 config	sudo ln -s /etc/nginx/sites-available/site1.conf /etc/nginx/sites-enabled/site1.conf	Symbolic link created
3	Test nginx config	sudo nginx -t	nginx: configuration file /etc/nginx/nginx.conf test is successful
4	Reload nginx	sudo systemctl reload nginx	nginx reloads with new site1 config active
5	Request to site1 domain	curl http://site1.example.com	Response served by site1 config

💡 After reload, nginx uses separate config files per site to route requests correctly.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4
sites-available/site1.conf	does not exist	created with server block	unchanged	unchanged	unchanged
sites-enabled/site1.conf	does not exist	does not exist	symbolic link created	unchanged	unchanged
nginx config status	unknown	unknown	unknown	test successful	reloaded with new config

Key Moments - 3 Insights

Why do we create config files in sites-available and not directly in sites-enabled?

sites-available holds all site configs safely; sites-enabled holds only active sites via links. This separation helps manage which sites are active without deleting configs. See execution_table steps 1 and 2.

What happens if nginx config test fails after adding a new site config?

nginx -t will show errors and prevent reload. This stops nginx from applying broken configs. See execution_table step 3 where test is successful; if it failed, reload would not happen.

Why do we need to reload nginx after adding or changing site configs?

Reload tells nginx to re-read config files and apply changes without downtime. Without reload, new configs are ignored. See execution_table step 4.

Visual Quiz - 3 Questions

Look at the execution table, what is the result of running 'nginx -t' at step 3?

A nginx: configuration file test is successful

B nginx reloads with new site1 config active

C Symbolic link created

D File created with server block for site1

💡 Hint

Check the 'Result/Output' column at step 3 in the execution_table.

At which step does the symbolic link get created to enable the site config?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Look at the 'Action' and 'Command/Config' columns in the execution_table for when 'ln -s' is run.

If you skip the reload step, what will happen when you request the site domain?

A Request will be served by the new site config

B Request will fail with error

C Request will be served by old config, ignoring new site

D nginx will automatically reload

💡 Hint

Refer to execution_table step 4 and 5 about reload and request handling.

Concept Snapshot

Separate config files per site in nginx:
- Place each site config in /etc/nginx/sites-available/
- Enable by linking to /etc/nginx/sites-enabled/
- Test config with 'nginx -t'
- Reload nginx to apply changes
- This keeps configs organized and active sites controlled

Full Transcript

This lesson shows how to manage multiple websites on nginx by using separate configuration files for each site. You create a config file for each site in the sites-available directory. Then you enable a site by creating a symbolic link to that file in sites-enabled. Before applying changes, you test the configuration with 'nginx -t' to avoid errors. Finally, you reload nginx to apply the new or changed site configurations. This method keeps your site configs organized and lets you easily enable or disable sites without deleting files.

Practice

1. What is the main benefit of using separate config files per site in nginx?

easy

A. It makes nginx run faster by loading fewer files.

B. It allows nginx to serve only one site at a time.

C. It automatically secures each site with HTTPS.

D. It keeps the nginx setup organized and easier to manage.

Solution

1. Step 1: Understand config file organization

   Separate config files help keep settings for each site distinct and clear.

2. Step 2: Recognize management benefits

   This organization makes it easier to update or troubleshoot individual sites without affecting others.

3. Final Answer:

   It keeps the nginx setup organized and easier to manage. -> Option D

4. Quick Check:

   Separate configs = better organization [OK]

Hint: Separate files mean easier site management [OK]

Common Mistakes:

• Thinking separate files speed up nginx
• Assuming separate files enable HTTPS automatically
• Believing nginx serves only one site with separate files

2. Which nginx directive correctly includes all site config files from the sites-enabled directory?

easy

A. include /etc/nginx/conf.d/*;

B. include /etc/nginx/sites-available/*;

C. include /etc/nginx/sites-enabled/*;

D. include /etc/nginx/sites-enabled.conf;

Solution

1. Step 1: Identify the correct directory for active sites

   The sites-enabled directory holds active site configs linked from sites-available.

2. Step 2: Use the include directive properly

   Using include /etc/nginx/sites-enabled/*; loads all enabled site configs.

3. Final Answer:

   include /etc/nginx/sites-enabled/*; -> Option C

4. Quick Check:

   Include sites-enabled/* loads active sites [OK]

Hint: Include sites-enabled/* to load active sites [OK]

Common Mistakes:

• Including sites-available instead of sites-enabled
• Using wrong directory like conf.d for site configs
• Missing the wildcard * to include all files

3. Given the command ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/, what is the effect?

medium

A. It creates a symbolic link to enable example.com site.

B. It copies the example.com config to sites-enabled.

C. It deletes the example.com config file.

D. It disables the example.com site.

Solution

1. Step 1: Understand the ln -s command

   The command creates a symbolic link from the source to the target location.

2. Step 2: Link sites-available to sites-enabled

   Linking example.com config into sites-enabled activates the site in nginx.

3. Final Answer:

   It creates a symbolic link to enable example.com site. -> Option A

4. Quick Check:

   ln -s from sites-available to sites-enabled enables site [OK]

Hint: ln -s link enables site by linking config [OK]

Common Mistakes:

• Thinking ln -s disables the site
• Assuming ln -s deletes or copies files
• Confusing symbolic link with file copy

4. You added a new site config in sites-available but forgot to link it in sites-enabled. What happens when you reload nginx?

medium

A. The new site is ignored and not served.

B. Nginx throws a syntax error and fails to reload.

C. The new site is active and served by nginx.

D. Nginx deletes the config file automatically.

Solution

1. Step 1: Understand sites-available vs sites-enabled

   Sites-available holds configs but only linked sites in sites-enabled are active.

2. Step 2: Effect of missing link on reload

   Without a link, nginx ignores the new config and serves only enabled sites.

3. Final Answer:

   The new site is ignored and not served. -> Option A

4. Quick Check:

   Missing link means site ignored on reload [OK]

Hint: Link site config to sites-enabled to activate [OK]

Common Mistakes:

• Expecting nginx to auto-enable new configs
• Thinking nginx reload fails without link
• Assuming nginx deletes unlinked configs

5. You want to add a new site with config in /etc/nginx/sites-available/newsite. Which sequence correctly enables it and reloads nginx safely?

hard

A. Copy config to sites-enabled, then run nginx -s reload

B. Create symbolic link in sites-enabled, test config with nginx -t, then reload nginx

C. Edit nginx.conf directly to add newsite, then restart nginx

D. Move config to sites-enabled, then reload nginx without testing

Solution

1. Step 1: Enable site by linking config

   Create a symbolic link from sites-available/newsite to sites-enabled to activate it.

2. Step 2: Test nginx config before reload

   Run nginx -t to check for syntax errors and avoid downtime.

3. Step 3: Reload nginx to apply changes

   Use nginx -s reload to apply new config without stopping the server.

4. Final Answer:

   Create symbolic link in sites-enabled, test config with nginx -t, then reload nginx -> Option B

5. Quick Check:

   Link + test + reload = safe enable [OK]

Hint: Always test config before reload after linking site [OK]

Common Mistakes:

• Copying instead of linking config files
• Reloading nginx without testing config
• Editing nginx.conf instead of using sites-available