Build an NGINX Traffic Gateway

Build a local NGINX gateway that proxies, balances, and caches HTTP traffic.

Introduction

30 Second Summary

A single web address can hide several destinations behind it. The difference becomes visible when requests fail, switch servers, or return faster the second time.

In this project, you will use NGINX to serve a local website through HTTP. You will then build a gateway whose traffic log reveals each backend choice and cache decision.

What You'll Build

You will demo a local gateway where refreshes alternate between two backend pages while the traffic log exposes cache misses and hits.

By the end of this project, you'll have:

A local gateway that displays its landing page at http://localhost:8080.
A reverse proxy you can deliberately break with a 502 Bad Gateway response before repairing it into a round-robin load balancer.
A visible response cache that changes from MISS to HIT in the traffic log.
Secret Mission: Give Backend A more traffic with weighted load balancing, then prove the new distribution across eight requests.

No prior NGINX experience is required. The project includes NGINX setup and every lab file.

Before We Start

Before We Start...

Before you dive in, lock in how your NGINX gateway will serve a local site, distribute application traffic, and cache repeated responses so you can observe each traffic role separately.

Install NGINX and Create the Lab

Your traffic gateway needs one predictable web server before you can trace requests. NGINX provides every server, proxy, load-balancing, and caching role in this local lab.

This step installs NGINX, checks the executable, and creates one project-local folder. Keeping the files together lets later commands use the same configuration without changing system-owned defaults.

In this step, get ready to:

Install NGINX for your operating system.
Confirm that the NGINX command runs.
Create and open the nginx-http-lab folder.

Install and check NGINX

The installation path differs by operating system. Run the version check first so you only install what your computer needs.

macOS

Press Cmd+Space to open Spotlight.
Type Terminal and press Enter.
Check your NGINX version by running:

nginx -v

Windows

Press the Windows key to open search.
Type PowerShell and press Enter.
Move to the extracted NGINX folder by running:

Set-Location C:\nginx-1.31.4

Check your NGINX version by running:

.\nginx.exe -v

Linux

Open Terminal from your application menu.
Check your NGINX version by running:

nginx -v

Choose the outcome that matches your terminal.

✔️ I see an NGINX version

Your terminal prints an NGINX version. The executable is ready for the project-local lab.

ⓧ I see an older version

An older installation may behave differently from the current mainline build. Use the official installation path for your operating system below, then run the version check again.

macOS

Update NGINX with Homebrew by running:

brew install nginx

Windows

Open the official NGINX for Windows guide.
Download nginx-1.31.4.zip.
Extract the archive to C:\nginx-1.31.4.

Linux

Open the official NGINX package guide.
Configure the documented mainline repository for your supported Ubuntu release.
Update the package list and install NGINX by running:

sudo apt update
sudo apt install nginx

ⓧ Command not found

Install NGINX through the official path for your operating system, then repeat the version check.

macOS

Install NGINX with Homebrew by running:

brew install nginx

The first installation can take a minute while Homebrew downloads the package. Your terminal returns to the prompt when it is ready.

Windows

Open the official NGINX for Windows guide.
Download nginx-1.31.4.zip.
Extract the archive to C:\nginx-1.31.4.
Confirm that nginx.exe sits directly inside the extracted folder.

Linux

Open the official NGINX package guide.
Configure the documented mainline repository for your supported Ubuntu release.
Update the package list and install NGINX by running:

sudo apt update
sudo apt install nginx

Version check still failing?

Confirm that you opened a new terminal after installing NGINX. On Windows, run .\nginx.exe -v from C:\nginx-1.31.4.

Help me troubleshoot the installation.

Create the lab folders

A project-local prefix keeps the configuration, pages, logs, and cache under one directory. The same layout works across every later step.

macOS

Move to your Desktop and create the lab folders by running:

cd ~/Desktop
mkdir -p nginx-http-lab/conf nginx-http-lab/html/gateway nginx-http-lab/html/backend-a nginx-http-lab/html/backend-b nginx-http-lab/logs nginx-http-lab/cache

Confirm the folder names by running:

ls nginx-http-lab

You should see cache, conf, html, and logs.

Windows

Create the project folders inside C:\nginx-1.31.4 by running:

Set-Location C:\nginx-1.31.4
New-Item -ItemType Directory -Force nginx-http-lab\conf, nginx-http-lab\html\gateway, nginx-http-lab\html\backend-a, nginx-http-lab\html\backend-b, nginx-http-lab\logs, nginx-http-lab\cache

Confirm the folder names by running:

Get-ChildItem nginx-http-lab

You should see cache, conf, html, and logs.

Linux

Move to your Desktop and create the lab folders by running:

cd ~/Desktop
mkdir -p nginx-http-lab/conf nginx-http-lab/html/gateway nginx-http-lab/html/backend-a nginx-http-lab/html/backend-b nginx-http-lab/logs nginx-http-lab/cache

Confirm the folder names by running:

ls nginx-http-lab

You should see cache, conf, html, and logs.

Open the lab in VS Code

Press Cmd+Space on macOS or the Windows key on Windows to open search.
Type Visual Studio Code and press Enter.
Click File in the top menu.
Click Open Folder.
Select the nginx-http-lab folder you created.
Click Open.

You should see cache, conf, html, and logs in the Explorer sidebar.

Your NGINX executable and project folders are ready. Next, you will serve the gateway's first page on port 8080.

Serve Your First Website

Your NGINX installation and lab folders are ready. Now the gateway needs a page it can return to a browser.

You will connect a landing page to port 8080 with a project-local configuration. This gives you the first visible request path before proxying enters the picture.

In this step, get ready to:

Create the gateway landing page.
Configure NGINX to serve the page on port 8080.
Start the gateway and load it in your browser.

Create the gateway page

Select the html/gateway folder in the VS Code Explorer sidebar.
Click the New File icon in the Explorer toolbar.
Name the file index.html.
Build the landing page by adding this code to html/gateway/index.html:

<!doctype html>
<html lang="en">
<head>
  <!-- Keep the page readable on desktop and mobile screens. -->
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>NGINX Traffic Gateway</title>
</head>
<body>
  <!-- Make the successful gateway response easy to recognise. -->
  <h1>NGINX Traffic Gateway</h1>
  <p>Your local gateway is serving this page on port 8080.</p>
</body>
</html>

What does this page show?

The heading gives the response a visible identity in your browser.
The paragraph names port 8080 so you can connect the page to the gateway configuration.

Save html/gateway/index.html.
Confirm that index.html appears inside html/gateway in the Explorer sidebar.

Can't find the gateway page?

Check that the file sits inside html/gateway and that its name ends in .html.

Help me check my gateway page.

✔️ Awesome, I've got everything!

Your saved gateway page is ready for NGINX to serve.

ⓧ I'd like to double check the full code

<!doctype html>
<html lang="en">
<head>
  <!-- Keep the page readable on desktop and mobile screens. -->
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>NGINX Traffic Gateway</title>
</head>
<body>
  <!-- Make the successful gateway response easy to recognise. -->
  <h1>NGINX Traffic Gateway</h1>
  <p>Your local gateway is serving this page on port 8080.</p>
</body>
</html>

Configure the gateway

An NGINX configuration nests a server inside the http context. The server below listens for local HTTP requests and maps them to your gateway page.

Select the conf folder in the VS Code Explorer sidebar.
Click the New File icon in the Explorer toolbar.
Name the file nginx.conf.
Configure the gateway by adding this code to conf/nginx.conf:

worker_processes 1;
error_log logs/error.log info;
pid logs/nginx.pid;

events {
    worker_connections 512;
}

http {
    default_type text/html;
    log_format gateway '$remote_addr "$request" $status upstream=$upstream_addr cache=$upstream_cache_status';
    access_log logs/traffic.log gateway;

    server {
        listen 8080;
        server_name localhost;
        root html/gateway;

        location / {
            try_files $uri $uri/ =404;
        }
    }
}

What does this configuration do?

listen 8080; accepts browser requests without using privileged port 80.
root html/gateway; maps the request path to your gateway page.
access_log records each request in the project-local traffic log.

Save conf/nginx.conf.
Confirm that the events, http, server, and location blocks are nested in that order.

✔️ Awesome, I've got everything!

Your gateway configuration is saved and ready to test.

ⓧ I'd like to double check the full code

worker_processes 1;
error_log logs/error.log info;
pid logs/nginx.pid;

events {
    worker_connections 512;
}

http {
    default_type text/html;
    log_format gateway '$remote_addr "$request" $status upstream=$upstream_addr cache=$upstream_cache_status';
    access_log logs/traffic.log gateway;

    server {
        listen 8080;
        server_name localhost;
        root html/gateway;

        location / {
            try_files $uri $uri/ =404;
        }
    }
}

Start and verify the gateway

Before you start NGINX, what page do you expect to see at port 8080?

macOS

Return to the terminal in the parent folder of nginx-http-lab.
Test and start the project-local gateway by running these commands:

nginx -p "$PWD/nginx-http-lab/" -c conf/nginx.conf -t
nginx -p "$PWD/nginx-http-lab/" -c conf/nginx.conf

Windows

Return to PowerShell in C:\nginx-1.31.4.
Test and start the project-local gateway by running these commands:

.\nginx.exe -p nginx-http-lab/ -c conf/nginx.conf -t
.\nginx.exe -p nginx-http-lab/ -c conf/nginx.conf

Linux

Return to the terminal in the parent folder of nginx-http-lab.
Test and start the project-local gateway by running these commands:

nginx -p "$PWD/nginx-http-lab/" -c conf/nginx.conf -t
nginx -p "$PWD/nginx-http-lab/" -c conf/nginx.conf

Open http://localhost:8080 in your browser.

You should see the NGINX Traffic Gateway heading and the sentence naming port 8080. That is your first complete browser-to-file request.

Gateway page not loading?

Check that the configuration test succeeds before the start command runs. Confirm that another NGINX process is not already using port 8080.

Help me troubleshoot the gateway.

Your browser can now reach a page through NGINX. Next, you will point a second route at an unavailable server and investigate the resulting 502 Bad Gateway.

Trigger a 502 Bad Gateway

Your NGINX gateway already serves a page from disk. A reverse proxy adds a second request path from the gateway to another server.

You will point the gateway at port 8999. You will trace the result through the browser plus the project logs.

In this step, get ready to:

Add a proxy route to the gateway configuration.
Test the configuration before gracefully reloading NGINX.
Trace the request from the browser to the error log.

Point the gateway at port 8999

A location block controls requests that match a path. The new block sends requests for /app/ to the destination defined by proxy_pass.

Select conf/nginx.conf in the VS Code Explorer sidebar.
Find the closing brace for the existing location / block.
Add this block directly below the existing location block:

        location /app/ {
            proxy_pass http://127.0.0.1:8999/;
        }

What Does This Code Do?

The location /app/ block matches requests whose paths begin with /app/.
The proxy_pass directive forwards each matching request to port 8999 on your computer.

Save conf/nginx.conf.
Confirm the new location /app/ block sits inside the gateway server block.

✔️ Awesome, I've got everything!

Your saved gateway configuration now contains the /app/ proxy route.

ⓧ I'd like to double check the full code

worker_processes 1;
error_log logs/error.log info;
pid logs/nginx.pid;

events {
    worker_connections 512;
}

http {
    default_type text/html;
    log_format gateway '$remote_addr "$request" $status upstream=$upstream_addr cache=$upstream_cache_status';
    access_log logs/traffic.log gateway;

    server {
        listen 8080;
        server_name localhost;
        root html/gateway;

        location / {
            try_files $uri $uri/ =404;
        }

        location /app/ {
            proxy_pass http://127.0.0.1:8999/;
        }
    }
}

Test and gracefully reload NGINX

A configuration test checks the syntax plus the referenced files before NGINX applies an edit. A successful result gives you a safe point for a graceful reload.

macOS

Return to the terminal at the parent folder of nginx-http-lab.
Test the project configuration by running this command:

nginx -p "$PWD/nginx-http-lab/" -c conf/nginx.conf -t

What Does This Command Check?

The command loads conf/nginx.conf with nginx-http-lab as the path prefix. The -t flag checks the configuration before it reaches the running process.

The terminal reports that the syntax is okay. It also reports that the configuration test is successful.

Return to the launch command you used for this project.
Add -s reload to the end of the command.
Run the updated command to gracefully reload the project configuration.

The command returns control to the terminal. The running NGINX process now uses the new route.

Windows

Return to PowerShell in C:\nginx-1.31.4.
Test the project configuration by running this command:

.\nginx.exe -p nginx-http-lab/ -c conf/nginx.conf -t

What Does This Command Check?

The command loads conf/nginx.conf with nginx-http-lab as the path prefix. The -t flag checks the configuration before it reaches the running process.

PowerShell reports that the syntax is okay. It also reports that the configuration test is successful.

Return to the launch command you used for this project.
Add -s reload to the end of the command.
Run the updated command to gracefully reload the project configuration.

The command returns control to PowerShell. The running NGINX process now uses the new route.

Linux

Return to the terminal at the parent folder of nginx-http-lab.
Test the project configuration by running this command:

nginx -p "$PWD/nginx-http-lab/" -c conf/nginx.conf -t

What Does This Command Check?

The command loads conf/nginx.conf with nginx-http-lab as the path prefix. The -t flag checks the configuration before it reaches the running process.

The terminal reports that the syntax is okay. It also reports that the configuration test is successful.

Return to the launch command you used for this project.
Add -s reload to the end of the command.
Run the updated command to gracefully reload the project configuration.

The command returns control to the terminal. The running NGINX process now uses the new route.

Does the Configuration Test Fail?

Check the reported line in conf/nginx.conf. A missing brace near the new location block prevents the test from succeeding.

Confirm that the proxy_pass line ends correctly. Confirm that the new block appears before the gateway server's final closing brace.

Help me diagnose my NGINX configuration test.

Trace the failed upstream request

Before you load the route, what do you expect the gateway to return? What must happen after the browser reaches port 8080?

Switch back to the browser from earlier.
Enter http://localhost:8080/app/ in the address bar.
Load the route.

The browser shows 502 Bad Gateway. This planned failure occurs because nothing answers the gateway on port 8999.

Switch back to VS Code.
Select logs/error.log in the Explorer sidebar.
Find the newest entry for the /app/ request.
Identify the failed upstream connection to 127.0.0.1:8999.

What Does the Failure Prove?

The browser successfully reached the gateway on port 8080. The error log proves that the gateway could not complete its separate upstream connection on port 8999.

The traffic log records the /app/ request. The two logs expose both sides of the gateway.

You have traced a browser request to an unavailable upstream. Next, you will replace that empty destination with two working backends.

Fix the Proxy and Balance Traffic

Your planned 502 response proved that the gateway receives requests. It also showed that a reverse proxy needs a working destination.

You will add two NGINX backend servers. An upstream group will distribute requests between them using round-robin load balancing.

In this step, get ready to:

Create a page for each backend server.
Configure two backend server blocks.
Send gateway traffic through a load-balanced upstream group.

Create the backend pages

Each backend page needs a visible label. The labels reveal which server answered a request.

Select the html/backend-a folder in the VS Code Explorer sidebar.
Click the New File icon in the Explorer toolbar.
Name the file index.html.
Build the Backend A page by adding this code to html/backend-a/index.html:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Backend A</title>
</head>
<body>
  <h1>Backend A</h1>
  <p>NGINX forwarded this request to port 8081.</p>
</body>
</html>

What does this page show?

The heading identifies this response as Backend A.
The paragraph makes port 8081 visible in the browser.

Save html/backend-a/index.html.
Confirm that index.html appears inside html/backend-a in the Explorer sidebar.

Can't find the Backend A file?

Check that index.html sits inside html/backend-a. A file inside html/backend-b would belong to the other server.

Help me check my Backend A file location.

✔️ Awesome, I've got everything!

Great. Backend A now has its own page.

ⓧ I'd like to double check the full code

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Backend A</title>
</head>
<body>
  <h1>Backend A</h1>
  <p>NGINX forwarded this request to port 8081.</p>
</body>
</html>

Select the html/backend-b folder in the VS Code Explorer sidebar.
Click the New File icon in the Explorer toolbar.
Name the file index.html.
Build the Backend B page by adding this code to html/backend-b/index.html:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Backend B</title>
</head>
<body>
  <h1>Backend B</h1>
  <p>NGINX forwarded this request to port 8082.</p>
</body>
</html>

What does this page show?

The heading identifies this response as Backend B.
The paragraph makes port 8082 visible in the browser.

Save html/backend-b/index.html.
Confirm that index.html appears inside html/backend-b in the Explorer sidebar.

Can't find the Backend B file?

Check that index.html sits inside html/backend-b. Confirm that its heading says Backend B.

Help me check my Backend B file location.

✔️ Awesome, I've got everything!

Great. Both backend pages are ready.

ⓧ I'd like to double check the full code

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Backend B</title>
</head>
<body>
  <h1>Backend B</h1>
  <p>NGINX forwarded this request to port 8082.</p>
</body>
</html>

Configure the backend servers

A backend is a server that receives forwarded work from the gateway. Each server block connects one loopback port to its matching page folder.

Return to conf/nginx.conf in VS Code.
Find the closing brace for the gateway server block.
Add the Backend A server block below it:

    server {
        listen 127.0.0.1:8081;
        server_name backend-a;
        root html/backend-a;

        add_header X-Backend A always;
        add_header Cache-Control no-store always;

        location / {
            try_files $uri $uri/ =404;
        }
    }

How does Backend A work?

The server listens for local requests on port 8081.
The document root points to html/backend-a.
The response headers identify Backend A. They also prepare the deliberate cache behavior used later.

Save conf/nginx.conf.
Repeat the configuration test command from Step 2.
Repeat the graceful reload command from Step 3.
Visit http://127.0.0.1:8081 in your browser.

The page shows Backend A. It also says that NGINX forwarded the request to port 8081.

Backend A not loading?

Confirm that the new server block remains inside the http block. Check that its root matches html/backend-a.

Help me debug the Backend A server block.

Return to conf/nginx.conf in VS Code.
Find the closing brace for the Backend A server block.
Add the Backend B server block below it:

    server {
        listen 127.0.0.1:8082;
        server_name backend-b;
        root html/backend-b;

        add_header X-Backend B always;
        add_header Cache-Control no-store always;

        location / {
            try_files $uri $uri/ =404;
        }
    }

How does Backend B work?

The server listens for local requests on port 8082.
The document root points to html/backend-b.
The response headers identify Backend B. Its settings mirror Backend A on a different port.

Save conf/nginx.conf.
Repeat the configuration test command from Step 2.
Repeat the graceful reload command from Step 3.
Visit http://127.0.0.1:8082 in your browser.

The page shows Backend B. It also says that NGINX forwarded the request to port 8082.

Backend B not loading?

Confirm that Backend B listens on port 8082. Check that its root matches html/backend-b.

Help me debug the Backend B server block.

Balance requests across both backends

An upstream group gives multiple servers one shared name. NGINX uses weighted round-robin by default to choose a server for each request.

Return to conf/nginx.conf in VS Code.
Find the gateway server block inside the http block.
Add the upstream group above the gateway server block:

    upstream backend_pool {
        server 127.0.0.1:8081;
        server 127.0.0.1:8082;
    }

What does the upstream group do?

The name backend_pool represents both backend addresses.
Each server has the default weight of 1. Requests therefore rotate evenly between the two backends.

Save conf/nginx.conf.
Repeat the configuration test command from Step 2.

The terminal reports that the syntax is okay. It also reports that the configuration test is successful.

Configuration test failing?

Confirm that upstream backend_pool sits inside the http block. Check each closing brace against the snippet.

Help me fix my upstream group.

Find the existing location /app/ block in the gateway server.
Replace that block with this load-balanced proxy configuration:

        location /app/ {
            proxy_pass http://backend_pool/;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }

How does the fixed proxy work?

The proxy sends each request to the named backend_pool group.
The forwarded headers preserve the original host. They also pass the requesting address to the selected backend.
The trailing slash sends the request to the matching path under the backend document root.

Save conf/nginx.conf.
Repeat the configuration test command from Step 2.
Repeat the graceful reload command from Step 3.
Predict whether Backend A or Backend B will answer the next request before you refresh.
Visit http://localhost:8080/app/ in your browser.
Refresh the page several times.

The page alternates between Backend A and Backend B. The planned 502 response has been replaced by working backend pages.

Return to logs/traffic.log in VS Code.
Inspect the newest records for repeated /app/ requests.

The upstream address alternates between 127.0.0.1:8081 and 127.0.0.1:8082. This proves that the gateway is distributing requests across both backends.

Still seeing a 502 response?

Confirm that proxy_pass points to http://backend_pool/. Check that both backend server blocks remain inside the http block.

Help me debug the load-balanced proxy.

✔️ Awesome, I've got everything!

Great. Save every file before moving on.

ⓧ I'd like to double check the full code

The complete configuration is longer than 30 lines. Scroll up to confirm these chunks appear in this order inside the existing http block.

The upstream backend_pool block appears before the gateway server.
The gateway location /app/ block proxies to http://backend_pool/.
The Backend A server listens on 127.0.0.1:8081.
The Backend B server listens on 127.0.0.1:8082.
The existing worker settings remain above the http block.
The existing gateway server still listens on port 8080.

Secret mission

Give Backend A More Traffic

Backend A can now receive a larger share of your gateway traffic. Change one upstream weight, then prove the new distribution through eight requests.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely locally, so there are no ongoing costs.

Resources you used:

One project-local NGINX process serving the gateway plus two backends.
The nginx-http-lab folder containing your configuration, pages, cache, traffic log, and error log.

Keep everything running

No action needed. Choose this if you are still actively testing the gateway routes.

Leave the project-local NGINX process running.
Keep the nginx-http-lab folder so you can revisit the gateway, backends, cache data, and logs.

Pause - I'll come back to this later

Shut down the running process to free its ports. Your project files remain ready for another session.

Select your operating system below to stop the project-local process.

macOS

Return to the terminal location you used for your last reload.
Keep the same project prefix and conf/nginx.conf arguments.
Replace -s reload with -s quit in that command.
Run the updated command.
Refresh http://localhost:8080 in your browser.

The gateway no longer loads. This confirms that the project-local process stopped.

Windows

Return to PowerShell in C:\nginx-1.31.4.
Keep the same project prefix and conf/nginx.conf arguments.
Replace -s reload with -s quit in that command.
Run the updated command.
Refresh http://localhost:8080 in your browser.

The gateway no longer loads. This confirms that the project-local process stopped.

Linux

Return to the terminal location you used for your last reload.
Keep the same project prefix and conf/nginx.conf arguments.
Replace -s reload with -s quit in that command.
Run the updated command.
Refresh http://localhost:8080 in your browser.

The gateway no longer loads. This confirms that the project-local process stopped.

Delete - I don't want to use this again

Remove all project resources to start fresh. Your separate NGINX installation remains available for future projects.

Select your operating system below to stop the process and remove the project folder.

macOS

Return to the terminal location you used for your last reload.
Keep the same project prefix and conf/nginx.conf arguments.
Replace -s reload with -s quit in that command.
Run the updated command.
Close VS Code.
Use Finder to delete the nginx-http-lab folder from the parent folder where you created it.

Confirm that the folder no longer appears in Finder. This removes the configuration, pages, cache data, and project logs.

Windows

Return to PowerShell in C:\nginx-1.31.4.
Keep the same project prefix and conf/nginx.conf arguments.
Replace -s reload with -s quit in that command.
Run the updated command.
Close VS Code.
Use File Explorer to delete C:\nginx-1.31.4\nginx-http-lab.

Confirm that the folder no longer appears in File Explorer. This removes the configuration, pages, cache data, and project logs.

Linux

Return to the terminal location you used for your last reload.
Keep the same project prefix and conf/nginx.conf arguments.
Replace -s reload with -s quit in that command.
Run the updated command.
Close VS Code.
Use your file manager to delete the nginx-http-lab folder from the parent folder where you created it.

Confirm that the folder no longer appears in your file manager. This removes the configuration, pages, cache data, and project logs.

Nice Work!

Nice work! You built a local HTTP traffic gateway with NGINX. You proved how requests move through web serving, reverse proxying, caching, and load balancing.

You've learned how to:

Serve a static website through a local gateway at http://localhost:8080.
Diagnose a planned 502 Bad Gateway before configuring a reverse proxy that distributes requests across two backends.
Cache an upstream response and confirm MISS followed by HIT in the traffic log.
Secret Mission: Apply weighted round-robin load balancing so Backend A receives three times the configured share of Backend B.

Ready to quiz yourself?