Nginx Deep Dive — How One Server Hosts Many Websites

We now reach the web-server layer.

You already understand:

Domain
 ↓
DNS
 ↓
IP
 ↓
Network
 ↓
TCP 443
 ↓
TLS
 ↓
HTTP

Now we need to understand what happens when that request reaches Nginx.

1. What Is Nginx?

Nginx is a high-performance web server and reverse proxy.

It can:

serve static files
handle HTTP/HTTPS
route domains
forward PHP requests
act as reverse proxy
handle redirects
serve cached content

For your hosting platform:

Internet
   ↓
Nginx
   ↓
PHP-FPM
   ↓
WordPress
   ↓
MySQL

2. Nginx Is Not WordPress

This distinction is important.

Nginx
=
web server

while:

WordPress
=
web application

Nginx receives the network request.

WordPress generates the application response.

3. Static vs Dynamic

Suppose the browser requests:

/logo.png

Nginx may directly return the file:

Browser
 ↓
Nginx
 ↓
logo.png

No PHP required.

4. Dynamic Request

Now:

/about/

may require WordPress.

The flow becomes:

Browser
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
 ↓
PHP-FPM
 ↓
Nginx
 ↓
Browser

5. Nginx Master Process

When Nginx starts, there is normally a:

Master process

Its responsibilities include things such as:

read configuration
manage worker processes
handle signals
reload configuration

6. Worker Processes

Nginx also uses:

Worker processes

Workers handle network requests.

Conceptually:

Nginx
│
├── Master
│
├── Worker
├── Worker
├── Worker
└── Worker

The exact number depends on configuration and workload.

7. Check Nginx Processes

Run:

ps aux | grep nginx

You may see:

root      nginx: master process
www-data  nginx: worker process
www-data  nginx: worker process

The exact user and process details depend on your configuration.

8. Why Master Can Be Root

Nginx may start with elevated privileges so it can perform privileged operations such as binding to low-numbered ports.

Then worker processes can run with a less-privileged user.

This follows the same principle we studied earlier:

root
 ↓
privileged setup
 ↓
lower privilege workers

9. Low Ports

Ports below 1024 traditionally require elevated privileges to bind on Linux.

For example:

80
443

Therefore the master process may start with sufficient privilege to bind them.

Worker processes then handle requests with reduced privileges.

10. Configuration

Nginx’s main configuration is commonly:

/etc/nginx/nginx.conf

But your installation may include additional configuration directories.

Common structure:

/etc/nginx/
├── nginx.conf
├── sites-available/
├── sites-enabled/
├── conf.d/
└── ...

The exact layout depends on the distribution and installation.

11. Main Configuration

Check:

sudo nginx -t

This tests configuration syntax.

You can inspect the main file:

sudo nano /etc/nginx/nginx.conf

or:

sudo less /etc/nginx/nginx.conf

12. `http` Block

Nginx configuration has hierarchical blocks.

Conceptually:

http {
    server {
        ...
    }

    server {
        ...
    }
}

The http block contains HTTP configuration.

13. Server Block

server

block represents a virtual server configuration.

For example:

server {
    listen 80;
    server_name example.com;
}

This is how Nginx can host multiple websites on one IP.

14. Multiple Websites

Suppose your server has:

203.0.113.25

and:

site1.com
site2.com
site3.com

All point to that IP.

Nginx can have:

server block 1
→ site1.com

server block 2
→ site2.com

server block 3
→ site3.com

15. `server_name`

The most important directive for virtual hosting is:

server_name site1.com www.site1.com;

This tells Nginx which hostnames the server block is intended to handle.

16. Example

server {
    listen 80;
    server_name learn.cresignsys.com;

    root /storage/websites/learn.cresignsys.com/public;
}

Now:

Host:
learn.cresignsys.com

can select this server block.

17. `listen`

This directive tells Nginx which address/port the server block listens on.

Example:

listen 80;

or HTTPS:

listen 443 ssl;

Modern configurations can also use additional directives for HTTP/2/HTTP/3 depending on Nginx version and configuration.

18. One Server, Many `server` Blocks

Example:

server {
    listen 80;
    server_name site1.com;

    root /storage/websites/site1.com/public;
}

server {
    listen 80;
    server_name site2.com;

    root /storage/websites/site2.com/public;
}

Both can use:

203.0.113.25:80

19. How Nginx Knows Which One?

The request contains the hostname.

For example:

Host: site2.com

Nginx searches its matching server configuration.

Conceptually:

Host: site2.com
        ↓
server_name site2.com
        ↓
site2 configuration

20. Default Server

What happens if no hostname matches?

Nginx uses the appropriate default server for that listen address/port.

Therefore, a request can sometimes display:

wrong website

even though DNS is correct.

This is a common hosting issue.

21. Example Problem

You configured:

siteA.com
siteB.com

But accidentally omitted:

server_name siteB.com;

Then:

siteB.com

may fall into another server block, potentially the default one.

22. `root`

The:

root

directive specifies the filesystem root for serving files.

Example:

root /storage/websites/site1.com/public;

Therefore:

URL:
/logo.png

Filesystem:
/storage/websites/site1.com/public/logo.png

for a direct static-file request, subject to Nginx location and rewrite rules.

23. Your Hosting Structure

Your current architecture is similar to:

/storage/websites/
│
├── learn.cresignsys.com/
│   └── public/
│
├── shop.cresignsys.com/
│   └── public/
│
├── manage.cresignsys.com/
│   └── public/
│
└── ...

This is a good foundation for a hosting platform.

24. Why `public`?

Keeping the web-accessible files inside:

public/

is useful.

For example:

site/
├── public/
│   ├── index.php
│   ├── wp-content/
│   └── ...
│
└── private/

Only:

public/

is exposed as the web root.

25. Security Benefit

Suppose your site has:

site/
├── public/
└── backups/

If Nginx root is:

site/public

then:

/backups/

is not automatically web-accessible.

This is much safer than making the entire site directory the document root.

26. `location`

Nginx uses:

location

blocks to control different URL paths.

Example:

location / {
    ...
}

means the general URL space.

27. Example

location /images/ {
    ...
}

can apply special behavior to:

/images/logo.png
/images/banner.jpg

28. Location Matching

Nginx has specific rules for choosing among multiple location blocks.

For example:

location / {
}

location /images/ {
}

location = /login {
}

The exact matching algorithm is important later.

For now remember:

location
=
URL-path processing rule

29. `try_files`

One of the most important directives for WordPress:

try_files

A common pattern is:

location / {
    try_files $uri $uri/ /index.php?$args;
}

30. What Does It Mean?

Conceptually:

Request
 ↓
Does the requested file exist?
 ↓
yes → serve it
 ↓
no
 ↓
Does the directory exist?
 ↓
yes → use it
 ↓
no
 ↓
send to index.php

This allows WordPress’s pretty URLs to work.

31. WordPress Pretty URL

Browser requests:

/about/

There may be no physical:

/about/index.html

Instead:

/about/
 ↓
index.php
 ↓
WordPress
 ↓
About page

32. Front Controller

This architecture is called a:

Front Controller

WordPress commonly uses:

index.php

as the central entry point.

So many URLs eventually reach:

index.php

33. PHP Location

Nginx needs a rule for PHP.

Conceptually:

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

The exact socket path depends on your PHP-FPM installation.

34. FastCGI

Nginx does not execute PHP itself.

Instead:

Nginx
 ↓
FastCGI
 ↓
PHP-FPM

FastCGI is a protocol/interface for communicating with application processes such as PHP-FPM.

35. PHP-FPM

PHP-FPM means:

PHP FastCGI Process Manager

It manages PHP worker processes.

Conceptually:

Nginx
   │
   ▼
PHP-FPM
   │
   ├── PHP worker
   ├── PHP worker
   ├── PHP worker
   └── PHP worker

36. Nginx Doesn’t Run PHP

This is worth memorizing:

Nginx
≠
PHP

Nginx handles:

HTTP
static files
proxying
routing

PHP-FPM handles:

PHP execution

37. Static Request

For:

/logo.png

the flow can be:

Browser
 ↓
Nginx
 ↓
/public/logo.png
 ↓
Browser

38. PHP Request

For:

/index.php

the flow can be:

Browser
 ↓
Nginx
 ↓
PHP-FPM
 ↓
PHP
 ↓
Nginx
 ↓
Browser

39. WordPress Request

For:

/about/

the flow is often:

Browser
 ↓
Nginx
 ↓
try_files
 ↓
index.php
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
 ↓
PHP
 ↓
Nginx
 ↓
Browser

40. One Server, Multiple PHP-FPM Pools

For professional hosting, you can eventually configure:

PHP-FPM
│
├── site1 pool → user1
├── site2 pool → user2
├── site3 pool → user3
└── ...

This provides better isolation than having every site share one PHP execution identity.

41. Site-Specific Socket

Each PHP-FPM pool can have its own socket.

Conceptually:

site1
 ↓
/run/php/site1.sock

site2
 ↓
/run/php/site2.sock

Nginx can then route each site’s PHP requests to its own pool.

42. Why This Is Powerful

Suppose:

site1

gets heavy traffic.

You can configure its PHP-FPM pool separately from:

site2

You can control things such as:

worker limits
process management
user
group
socket

43. Resource Isolation

This leads to a professional architecture:

siteA
 ↓
userA
 ↓
PHP pool A
 ↓
socket A

siteB
 ↓
userB
 ↓
PHP pool B
 ↓
socket B

Now sites are more strongly separated.

44. Your CresignSys Hosting Platform

Your automation can eventually create:

CREATE WEBSITE
       │
       ├── domain
       ├── directory
       ├── user
       ├── group
       ├── PHP-FPM pool
       ├── socket
       ├── Nginx server block
       ├── database
       ├── database user
       ├── DNS
       └── SSL

This is the architecture you are gradually building toward.

45. Nginx Configuration Generation

For:

learn.cresignsys.com

your automation could generate a configuration conceptually like:

server {
    listen 80;
    server_name learn.cresignsys.com;

    root /storage/websites/learn.cresignsys.com/public;

    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/learn.cresignsys.com.sock;
    }
}

This is a simplified teaching example; production configurations need additional security and PHP-FPM parameters.

46. Why Configuration Templates Matter

Imagine manually configuring:

1 website

Not too difficult.

But:

10 websites

becomes repetitive.

At:

100 websites

manual configuration becomes error-prone.

Therefore:

Template
+
Automation

becomes essential.

47. Your Hosting Script

Your hosting creation system can receive:

DOMAIN=example.com

and generate:

/storage/websites/example.com/public

then:

Nginx configuration
PHP-FPM pool
database
permissions
SSL

48. The Hosting Control Plane

This introduces an important concept:

Control Plane

Your management system decides:

What websites exist?
Who owns them?
Where are they stored?
Which PHP version?
Which database?
Which domain?
Which SSL certificate?

49. Data Plane

The actual traffic path is the:

Data Plane

Internet
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL

Your control panel manages the configuration.

The web stack serves the traffic.

50. Example

Your hosting platform might have:

Control Plane
       │
       ▼
Create Website
       │
       ├── Nginx config
       ├── PHP-FPM config
       ├── database
       └── SSL
       
Data Plane
       │
       ▼
Internet
       ↓
Nginx
       ↓
PHP
       ↓
WordPress

This distinction becomes very important when designing a real hosting service.

51. Nginx Reload

After generating configuration:

sudo nginx -t

First.

If successful:

sudo systemctl reload nginx

Never make blind configuration changes and immediately restart the server without testing the configuration.

52. Why `nginx -t` Is Important

Suppose your script generates:

server_name example.com

but forgets:

Nginx configuration becomes invalid.

If you reload blindly:

reload failure

could affect your hosting service.

Therefore:

Generate
 ↓
Validate
 ↓
Reload

53. Safe Automation Pattern

Your hosting script should conceptually do:

1. Validate domain
        ↓
2. Create directories
        ↓
3. Create user
        ↓
4. Set permissions
        ↓
5. Create PHP-FPM configuration
        ↓
6. Create Nginx configuration
        ↓
7. nginx -t
        ↓
8. Reload Nginx
        ↓
9. Configure database
        ↓
10. Configure SSL

Error handling becomes critical.

54. Nginx Logs

Common log directory:

/var/log/nginx/

You may find:

access.log
error.log

or per-site logs if your configuration defines them.

55. Access Log

An access log answers:

Did Nginx receive the request?

You may see:

GET /about/ HTTP/2
200

56. Error Log

The error log answers:

Did Nginx encounter a problem?

Examples:

permission denied
connect() failed
upstream timed out
no such file

57. Nginx + Permissions

Remember the previous lesson.

Nginx needs filesystem access.

If:

/storage/websites/example.com/public

cannot be traversed by the Nginx worker user, you may get:

403 Forbidden

58. Nginx + PHP-FPM

If:

Nginx
 ↓
PHP-FPM socket

is inaccessible:

502 Bad Gateway

may occur.

So permissions also apply to:

/run/php/

and the PHP-FPM socket.

59. Socket Permissions

Suppose:

/run/php/site.sock

belongs to:

siteuser:www-data

and has restrictive permissions.

Nginx must be able to access the socket.

Otherwise:

Nginx
 ↓
cannot connect
 ↓
502

60. This Connects Three Lessons

We now have:

Networking

TCP 443

Nginx

server_name
root
location

Linux permissions

user
group
socket/file permissions

These aren’t separate topics.

They interact.

61. Example Failure

Suppose:

DNS ✓
TCP 443 ✓
Nginx ✓

but:

Nginx → PHP-FPM socket ✗

Result:

502 Bad Gateway

The problem isn’t DNS.

It isn’t the domain.

It isn’t WordPress.

It is the Nginx-to-PHP-FPM layer.

62. Another Failure

Suppose:

DNS ✓
TCP ✓
Nginx ✓
PHP-FPM ✓

but:

WordPress directory
permissions ✗

Result may be:

403
500
file access errors

depending on exactly what operation failed.

63. Another Failure

Suppose everything works except:

MySQL

Then PHP may produce:

database connection error

The HTTP server is functioning.

The application backend isn’t.

64. Layered Architecture

Your complete website is now:

┌─────────────────────────────┐
│          INTERNET           │
└──────────────┬──────────────┘
               ↓
             DNS
               ↓
          Public IP
               ↓
        OCI Networking
               ↓
            TCP 443
               ↓
             Nginx
               ↓
        ┌──────┴──────┐
        ↓             ↓
   Static files     PHP-FPM
                      ↓
                  WordPress
                      ↓
                    MySQL

And:

Users
Groups
Permissions

control filesystem/process access underneath.

65. The Most Important Nginx Directives

For your current level, memorize these:

listen
server_name
root
index
location
try_files
include
fastcgi_pass

66. Their Meaning

listen
→ Which network endpoint?

server_name
→ Which domain?

root
→ Which filesystem directory?

index
→ Which default files?

location
→ Which URL rules?

try_files
→ Does the requested resource exist?

include
→ Load reusable configuration

fastcgi_pass
→ Where should PHP requests go?

67. One Website

learn.cresignsys.com
        ↓
Nginx
        ↓
/storage/websites/learn.cresignsys.com/public
        ↓
PHP-FPM
        ↓
WordPress

68. Ten Websites

Nginx
│
├── site1.com → PHP-FPM 1
├── site2.com → PHP-FPM 2
├── site3.com → PHP-FPM 3
├── site4.com → PHP-FPM 4
├── site5.com → PHP-FPM 5
└── ...

This is the foundation of a hosting server.

69. Hundreds of Websites

At larger scale:

Internet
    ↓
Load Balancer / Edge
    ↓
Web Servers
    ↓
PHP/Application Layer
    ↓
Database/Cache/Storage

A single VPS can host multiple sites, but at larger scale you start separating services and workloads.

70. Lesson 059 — Core Principle

The central idea is:

Nginx is the traffic director at the web-server layer.

It receives:

IP
 ↓
Port
 ↓
HTTP request

and determines:

Which domain?
 ↓
Which server block?
 ↓
Which URL rule?
 ↓
Static file or PHP?
 ↓
Which PHP-FPM backend?

That is the foundation of multi-domain hosting.

Next Lesson — 060

PHP-FPM Deep Dive — How Nginx Runs WordPress PHP

Next we go one level deeper:

Nginx
 ↓
FastCGI
 ↓
PHP-FPM
 ↓
Master process
 ↓
Worker pool
 ↓
PHP execution
 ↓
WordPress

We will learn:

PHP-FPM pools
users
groups
Unix sockets
TCP sockets
pm.max_children
pm.start_servers
pm.min_spare_servers
pm.max_spare_servers
pm.max_requests
memory usage
slow requests
502 errors

and how to design one PHP-FPM pool per website for your CresignSys hosting platform.

CresignSys Learn — Lesson 059

Nginx Deep Dive — How One Server Hosts Many Websites

1. What Is Nginx?

2. Nginx Is Not WordPress

3. Static vs Dynamic

4. Dynamic Request

5. Nginx Master Process

Master process

6. Worker Processes

Worker processes

7. Check Nginx Processes

8. Why Master Can Be Root

9. Low Ports

10. Configuration

11. Main Configuration

12. http Block

13. Server Block

14. Multiple Websites

15. server_name

16. Example

17. listen

18. One Server, Many server Blocks

19. How Nginx Knows Which One?

20. Default Server

21. Example Problem

22. root

23. Your Hosting Structure

24. Why public?

25. Security Benefit

26. location

27. Example

28. Location Matching

29. try_files

30. What Does It Mean?

31. WordPress Pretty URL

32. Front Controller

Front Controller

33. PHP Location

34. FastCGI

35. PHP-FPM

PHP FastCGI Process Manager

36. Nginx Doesn’t Run PHP

37. Static Request

38. PHP Request

39. WordPress Request

40. One Server, Multiple PHP-FPM Pools

41. Site-Specific Socket

42. Why This Is Powerful

43. Resource Isolation

44. Your CresignSys Hosting Platform

45. Nginx Configuration Generation

46. Why Configuration Templates Matter

47. Your Hosting Script

48. The Hosting Control Plane

Control Plane

49. Data Plane

Data Plane

50. Example

51. Nginx Reload

52. Why nginx -t Is Important

53. Safe Automation Pattern

54. Nginx Logs

55. Access Log

56. Error Log

57. Nginx + Permissions

58. Nginx + PHP-FPM

59. Socket Permissions

60. This Connects Three Lessons

Networking

Nginx

Linux permissions

61. Example Failure

62. Another Failure

63. Another Failure

64. Layered Architecture

65. The Most Important Nginx Directives

66. Their Meaning

67. One Website

68. Ten Websites

69. Hundreds of Websites

12. `http` Block

15. `server_name`

17. `listen`

18. One Server, Many `server` Blocks

22. `root`

24. Why `public`?

26. `location`

29. `try_files`

52. Why `nginx -t` Is Important