Scaling the LAMP Stack: High-Performance Nginx Reverse Proxy Configuration

Let’s be honest: Apache is a beast, but it’s a memory-hungry beast. If you are running a high-traffic site on a standard VPS, you have likely seen your load averages spike simply because Apache is spawning a new process for every single image, CSS file, and script request. It’s 2010, and throwing more RAM at the problem is not a strategy; it’s a waste of budget.

I recently audited a client’s setup hosting a large e-commerce platform targeting the Norwegian market. They were running a standard CentOS 5 stack with Apache 2.2. Every time a crawler hit them, the server swapped itself into oblivion. The fix wasn’t migrating to a dedicated cluster costing thousands of Kroner. The fix was architectural: putting Nginx in front of Apache.

In this guide, we will configure Nginx as a reverse proxy. Nginx will handle the heavy lifting of static files and connection handling, while Apache stays in the back, doing what it does best: processing PHP.

The Architecture: Why Event-Driven Wins

Apache uses a prefork mode (usually), meaning one thread per connection. Nginx is event-driven and asynchronous. It uses the epoll system call on Linux to handle thousands of connections within a single thread with very little memory footprint.

By placing Nginx on port 80 and Apache on port 8080, we offload the "dumb" work. Nginx serves the JPEGs and CSS instantly, and only passes dynamic PHP requests to the backend.

Prerequisites

• A VPS running Linux (CentOS 5.5 or Ubuntu 10.04 LTS recommended).
• Root access.
• Benchmarking tool (ab or siege) to prove I'm right.

Pro Tip: Hardware matters. Even the best config can't fix slow disk I/O. We run our benchmarks on CoolVDS instances because they utilize enterprise-grade SSD storage (still a rarity in this market) and RAID-10 SAS arrays. If you are waiting on disk seeks, your wait_io will kill your performance regardless of your Nginx config.

Step 1: Install Nginx (The Right Way)

Don't just yum install from the default repositories; they are often outdated. Use the EPEL repository or compile from source if you need specific modules like stub_status.

# On CentOS 5
rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
yum install nginx

Step 2: The Reverse Proxy Configuration

We need to modify nginx.conf. The goal is to define an upstream block for Apache and set appropriate headers so Apache knows the real IP of the visitor (critical for logs and security).

Here is a battle-tested configuration for /etc/nginx/nginx.conf:

user  nginx;
worker_processes  2; # Match this to your CPU cores

events {
    worker_connections  1024;
    use epoll;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    # Optimization Flags
    sendfile        on;
    tcp_nopush      on;
    tcp_nodelay     on;
    keepalive_timeout  65;
    gzip  on;

    # The Backend Definition
    upstream apache_backend {
        server 127.0.0.1:8080;
    }

    server {
        listen       80;
        server_name  example.no www.example.no;

        # Serve static files directly
        location ~* \.(jpg|jpeg|gif|png|css|js|ico|xml)$ {
            access_log        off;
            expires           30d;
            root /var/www/html;
        }

        # Pass everything else to Apache
        location / {
            proxy_pass http://apache_backend;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            
            # Timeouts for slow PHP scripts
            proxy_connect_timeout 90;
            proxy_send_timeout 90;
            proxy_read_timeout 90;
        }
    }
}

Step 3: Adjusting Apache

Now, you must tell Apache to stop listening on port 80 and move to 8080. Edit your httpd.conf:

# Listen 80
Listen 8080

You should also install mod_rpaf (Reverse Proxy Add Forward) on Apache. Without this, Apache will think every request is coming from 127.0.0.1 (localhost). This messes up your analytics and IP blocking scripts.

Latency and Local Compliance

For those of us operating in Norway, latency to the NIX (Norwegian Internet Exchange) is a critical metric. When your server is physically located in Oslo or nearby, your ping times drop from 30-40ms (hosting in Germany/UK) to sub-5ms. This "snappiness" is felt immediately by the end-user.

Furthermore, we have to consider the Personopplysningsloven (Personal Data Act). The Datatilsynet is becoming increasingly strict about where sensitive data is stored. Hosting on US-based clouds can introduce legal gray areas regarding safe harbor. Keeping your data on Norwegian soil, or at least within the EEA on strictly controlled infrastructure like CoolVDS, mitigates this risk. It's not just about speed; it's about sovereignty.

The "CoolVDS" Difference

Configuration is software, but software lives on hardware. You can tune Nginx buffers all day, but if your host over-sells CPU cycles, you will experience "stolen time" (check %st in top). This is common with budget VPS providers using OpenVZ.

At CoolVDS, we utilize KVM (Kernel-based Virtual Machine) technology. This ensures true hardware isolation. Your RAM is your RAM. Combined with our investment in high-speed SSD storage, this setup allows the Nginx configuration above to handle 5x the traffic of a standard SATA-based shared hosting plan.

Next Steps

Don't let your infrastructure become the bottleneck for your growth. SSH into your server, install Nginx, and give your Apache server a break. If you want to test this on hardware that doesn't blink under load, spin up a CoolVDS instance today. The network stability and I/O performance speak for themselves.