Nginx Server Setup: High-Level Overview

Table of Contents

nginx.conf

The main

nginx.conf

/etc/nginx/nginx.conf

• Worker processes: set to "auto" (scales to available CPU cores)
• Worker connections: 768 per worker
• Gzip compression: enabled: see section below
• SSL: TLSv1.2 and TLSv1.3 enabled; server cipher preference on
• Virtual host loading: includes all files from

  /etc/nginx/conf.d/*.conf

  and

  /etc/nginx/sites-enabled/*

Gzip Compression

When a browser sends a request it includes an

Accept-Encoding: gzip

"gzip on" in nginx.conf

This is useful because text-based assets - HTML, CSS, JavaScript, and JSON - often compress to 20–30% of their original size. A 100 KB JavaScript file might become ~25 KB over the wire, reducing both bandwidth consumption and page load time. Binary files (images, videos, already-compressed archives) gain little from gzip and are typically excluded.

The current config enables gzip at a basic level. The commented-out directives beneath it allow fine-grained control:

gzip_vary on

gzip_comp_level

gzip_types

gzip_min_length

These can be uncommented and tuned when optimising for production traffic.

sites-available vs sites-enabled

The two directories follow the standard Debian/Ubuntu Nginx convention:

/etc/nginx/sites-available/

/etc/nginx/sites-enabled/

Enabling and disabling sites

A site is enabled by creating a symbolic link from

sites-enabled

sites-available

# Enable a site
sudo ln -s /etc/nginx/sites-available/mysite /etc/nginx/sites-enabled/mysite

# Disable a site (remove the symlink, leave the original intact)
sudo rm /etc/nginx/sites-enabled/mysite

# Reload Nginx to apply the change
sudo nginx -t && sudo systemctl reload nginx

nginx -t

Static Sites

Static sites serve pre-built HTML/CSS/JS files directly from disk. No application server or proxy is needed — Nginx reads the files and sends them straight to the client.

Root directory convention: Place each site's files under

/var/www/<sitename>/

Example server block:

server {
    listen 80;
    server_name example.com www.example.com;
    root /var/www/example;
    index index.html;

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

    access_log /var/log/nginx/example_access.log;
    error_log /var/log/nginx/example_error.log;
}

Key points:

• "root" points to the directory containing "index.html" and all assets
• "try_files $uri $uri/ =404" attempts to serve the exact file path, then a directory index, and returns 404 if neither exists
• A non-standard port (e.g. "8083") can be used when the site sits behind another proxy or is for internal use only
• Per-site log files make debugging straightforward

Proxied Services — Connection to the k3s Cluster

Some server blocks act as reverse proxies, forwarding incoming HTTP requests through to backend services running inside a k3s Kubernetes cluster on the internal network.

How requests reach the cluster

Nginx forwards to an internal IP address on a specific port. That port is exposed by a Kubernetes "Service" of type "LoadBalancer", managed by the cluster's load balancer controller. The general flow is:

Internet → Nginx (public-facing, port 80)
         → LoadBalancer IP:port (internal network)
         → Kubernetes Service
         → Pod(s) running the application

Identifying the load balancer in use

From a service definition (

kubectl get service <name> -o yaml

status:
  loadBalancer:
    ingress:
    - ip: 192.168.2.6
      ipMode: VIP

The "ipMode: VIP" value is characteristic of k3s's built-in load balancer controller, ServiceLB (previously known as Klipper). The k3s documentation confirms that when ServiceLB assigns an ingress IP from a node's external IP it sets "ipMode: VIP". The cluster IP falling in the "10.43.x.x" range is also consistent with k3s's default service CIDR, further pointing to a vanilla k3s installation with ServiceLB active.

To confirm definitively:

# Look for svclb DaemonSet pods — these are created by ServiceLB for each LoadBalancer service
kubectl get daemonset -n kube-system | grep svclb

# Alternatively, inspect a specific service
kubectl describe service <service-name>

If "svclb-*" DaemonSet pods appear in

kube-system

kube-system

How ServiceLB works

For each "Service" of type "LoadBalancer", ServiceLB creates a DaemonSet in the "kube-system" namespace. The DaemonSet runs a small pod on every eligible node using "hostPort", which binds the service port directly to the node's network interface. This makes the service reachable at the node's IP on that port — no external hardware or cloud provider required.

The service YAML shows the result of this clearly:

ports:
- name: https
  nodePort: 32090   # Random high port allocated by Kubernetes
  port: 8003        # Port Nginx connects to (the LoadBalancer port)
  targetPort: 8000  # Port the application pod actually listens on

Traffic flow in detail:

1. Nginx connects to

   192.168.2.6:8003

2. ServiceLB receives it via "hostPort" on the node
3. Kubernetes routes it to the Service's "clusterIP"
4. kube-proxy forwards it to a healthy pod on "targetPort 8000"

Standard proxy configuration

All proxied location blocks use the same set of headers:

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $server_name;

# WebSocket upgrade support
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

X-Forwarded-For

X-Real-IP

Upgrade

Connection

Catch-All / Default Behaviour

A final

server

server_name

server {
    listen 80;
    server_name _;
    return 444;  # Close connection without response
}

Returning

444

Log Locations

Global and per-site logs are written to

/var/log/nginx/

access_log

error_log