Forward Proxy Architecture

A forward proxy acts as an intermediary for client devices seeking to access external resources. Positioned between internal users and destination servers, this architecture prevents direct communication between the client and target endpoints.

Operational Mechanics:

• The proxy server receives outbound requests from internal clients
• It establishes connections to external services on behalf of the requester
• Responses flow back through the proxy before reaching the originating client
• All external visibility shows only the proxy's network identity, masking internal topology

Primary Applications:

• Identity Masking: Conceals internal IP addresses and network structure from external observers
• Policy Enforcement: Implements URL filtering, content inspection, and bandwidth controls
• Protocol Translation: Bridges incompatible network protocols between legacy systems and modern services
• Caching Layer: Stores frequently requested external content to reduce bandwidth consumption

Implementation Configuration:

http {
    server {
        listen 3128;
        resolver 1.1.1.1 8.8.8.8;
        
        location / {
            proxy_pass $scheme://$host$request_uri;
            proxy_set_header Host $host;
            proxy_set_header X-Client-IP $remote_addr;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_connect_timeout 60s;
            proxy_send_timeout 60s;
            proxy_read_timeout 60s;
        }
    }
}

This configuration establishes a standard HTTP forward proxy on port 3128, utilizing public DNS resolvers and preserving original host headers while anonymizing client addresses.

Reverse Proxy and Load Balancing

Reverse proxies represent the inverse pattern, sitting infront of backend application servers to handle inbound client requests. Rather than protecting clients from servers, this architecture shields origin servers from direct client exposure.

Core Functions:

• Request Routing: Distributes incoming traffic across multiple backend instances based on various algorithms
• SSL Termination: Handles encryption/decryption at the edge, reducing computational load on application servers
• High Availability: Removes failed nodes from rotation automatically, ensuring service continuity
• Static Asset Caching: Stores images, stylesheets, and scripts closer to end users

Basic Reverse Proxy Setup:

http {
    upstream app_cluster {
        zone upstream_zone 64k;
        server srv01.internal:8080 weight=5;
        server srv02.internal:8080 weight=5;
        server srv03.internal:8080 backup;
        keepalive 32;
    }
    
    server {
        listen 80;
        server_name api.example.com;
        
        location / {
            proxy_pass http://app_cluster;
            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_http_version 1.1;
            proxy_set_header Connection "";
        }
    }
}

The upstream block defines a pool of application servers with weighted distribution and a designated backup node. Persistent connections reduce TCP handshake overhead.

Traffic Distribution Algorithms

Nginx supports multiple request distribution strategies, each optimized for specific workload characteristics and session requirements.

Weighted Round Robin

The default distribution method cycles through available servers sequentially while respecting assigned weight values. Higher weights receive proportionally more traffic.

upstream web_farm {
    server web01.local max_fails=3 fail_timeout=30s;
    server web02.local max_fails=3 fail_timeout=30s;
    server web03.local weight=2;
}

Suitable for homogeneous server environments where processing capacity varies predictably between nodes.

Least Connections

Routes each new request to the backend currently handling the fewest active connections. Accounts for request duration variations and uneven processing times.

upstream dynamic_cluster {
    least_conn;
    server app01.internal:8080;
    server app02.internal:8080;
    server app03.internal:8080;
}

Optimal for applications with long-lived connections, streaming content, or variable response times.

IP Hash Persistence

Calculates a hash value from the client IP address to determine server selection. Guarantees that specific clients consistently reach the same backend instance.

upstream session_aware {
    ip_hash;
    server node01.internal;
    server node02.internal;
    server node03.internal;
}

Essential for stateful applications requiring session affinity, such as shopping carts or authentication workflows where server-side session storage isn't shared.

Consistent Hashing

Distributes requests based on arbitrary key values—such as URI components, headers, or query parameters—using a hash ring algorithm. Minimizes cache invalidation during topology changes.

upstream cache_friendly {
    hash $request_uri consistent;
    server cache01.internal;
    server cache02.internal;
    server cache03.internal;
}

Maximizes cache hit rates in distributed caching layers by ensuring identical resources always route to the same cache node.

Advanced Hybrid Configuration

Complex deployments often combine multiple techniques:

upstream hybrid_backend {
    zone upstream_memory 128k;
    least_conn;
    
    server 10.0.1.10:8080 weight=3;
    server 10.0.1.11:8080 weight=3;
    server 10.0.1.12:8080 weight=1 backup;
    
    keepalive 64;
    keepalive_timeout 60s;
    keepalive_requests 1000;
}

server {
    listen 443 ssl http2;
    server_name platform.example.com;
    
    ssl_certificate /etc/ssl/certs/platform.crt;
    ssl_certificate_key /etc/ssl/private/platform.key;
    
    location /api/ {
        proxy_pass http://hybrid_backend;
        proxy_set_header X-Request-ID $request_id;
        proxy_cache_bypass $http_pragma;
        proxy_no_cache $http_authorization;
    }
}

This configuration implements least connections distribution with weighted priorities, connection pooling, and dedicated backup nodes for failover scenarios.