Set Up a Reverse Proxy with Nginx

By Kokil Thapa | Last reviewed: August 2026

You need to set up a reverse proxy with Nginx when your application runs on an internal port or socket but must be served securely over standard HTTP/HTTPS ports. Whether you are deploying a Laravel API, a Node.js service, or a legacy PHP application, Nginx acts as the secure gateway that handles SSL termination, load balancing, and static asset delivery while your backend focuses solely on business logic. This architecture is the default for most production systems I maintain because it isolates application concerns from network security.

For developers building full-stack applications in Nepal or globally, understanding this layer is non-negotiable. It directly impacts your site's security posture and Core Web Vitals. If you are also managing the application layer, my guide on being a full-stack developer in Nepal covers how these infrastructure decisions integrate with application architecture. Getting the proxy right prevents common issues like lost client IPs, broken WebSocket connections, and mixed-content errors that plague new deployments.

How Do You Set Up a Reverse Proxy with Nginx for Backend Applications?

The fundamental mechanism of a reverse proxy is straightforward: Nginx accepts incoming traffic on public ports and forwards it to an upstream backend. However, a production-ready configuration requires more than just a proxy_pass directive. You must preserve client information, handle protocol upgrades, and manage timeouts appropriately.

Essential Proxy Headers and Configuration

When Nginx forwards a request, the backend sees the connection as coming from 127.0.0.1. Without explicit headers, your application loses the original client IP, protocol, and host. For Laravel applications relying on TrustProxies middleware or rate limiting, this causes immediate failures. The following configuration block should be included in every proxy setup:

location / {
    proxy_pass http://127.0.0.1:8000;
    
    # Preserve original client information
    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;
    
    # Timeout tuning for long-running requests
    proxy_connect_timeout 60s;
    proxy_send_timeout 60s;
    proxy_read_timeout 60s;
    
    # Buffer settings for large responses
    proxy_buffering on;
    proxy_buffer_size 16k;
    proxy_buffers 4 64k;
}

In practice, I have debugged countless "infinite redirect" loops caused by missing X-Forwarded-Proto headers. When your backend generates HTTPS URLs but receives plain HTTP from the proxy, frameworks like Laravel and Symfony detect a mismatch and redirect endlessly. Always verify this header matches your actual SSL termination point.

What Are the Best Nginx Reverse Proxy Configs for Laravel and Node.js?

Different backends require different proxy strategies. A Laravel application running behind PHP-FPM has fundamentally different needs than a Node.js Express server or a Python Gunicorn process. Using a generic template leads to suboptimal performance and subtle bugs.

Laravel-Specific Optimizations

For Laravel, never proxy static assets through PHP-FPM. Configure Nginx to serve files from /public directly with aggressive caching headers. Only route non-file requests to the backend. This single change typically reduces backend load by 60–80% on content-heavy sites like legal portals or e-commerce stores.

# Serve static files directly - bypass PHP entirely
location ~* \.(css|js|jpg|jpeg|png|gif|ico|svg|woff2?)$ {
    root /var/www/laravel-app/public;
    expires 30d;
    add_header Cache-Control "public, immutable";
    try_files $uri =404;
}

# Route everything else to Laravel
location / {
    try_files $uri $uri/ /index.php?$query_string;
}

location ~ \.php$ {
    fastcgi_pass unix:/run/php/php8.4-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
    include fastcgi_params;
}

Node.js and WebSocket Proxying

Node.js applications often use WebSockets for real-time features. Standard HTTP proxying does not support the Upgrade mechanism required for WS/WSS protocols. You must explicitly enable header upgrading or WebSocket connections will fail silently after the initial handshake.

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 443 ssl;
    server_name app.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        
        # Critical for WebSocket support
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        
        # Disable buffering for streaming/SSE
        proxy_buffering off;
        proxy_cache off;
    }
}

On projects like Adventure Third Pole Trek where we use Laravel Livewire alongside real-time booking updates, getting this WebSocket proxy configuration correct was essential. Missing the proxy_http_version 1.1 directive alone will break all persistent connections regardless of other settings.

How Do You Configure SSL Termination and Security Hardening?

One primary reason to set up a reverse proxy with Nginx is centralized SSL management. Your backend applications should never handle TLS directly. Nginx terminates encryption at the edge, forwarding decrypted traffic internally. This simplifies certificate renewal, enables modern cipher suites without application changes, and reduces CPU overhead on app servers.

Modern SSL Configuration for 2026

Certificate management in 2026 should be fully automated via Certbot or acme.sh. Manual certificate handling is a liability. Below is a hardened SSL configuration compatible with all modern browsers while maintaining backward compatibility for older enterprise clients still present in some Nepal government and banking integrations:

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

# Modern cipher suite prioritizing AEAD ciphers
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;

# Session resumption for performance
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;

# HSTS - enforce HTTPS for 1 year including subdomains
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Security Headers and Rate Limiting

A reverse proxy is the ideal place to enforce security policies consistently across multiple backends. Rather than configuring headers in each application, define them once in Nginx. This approach proves invaluable when maintaining multiple sister sites sharing infrastructure, as I do with several legal-tech portals deployed via Deployer 7.

• X-Content-Type-Options: Prevent MIME-type sniffing attacks
• X-Frame-Options: Block clickjacking by denying iframe embedding
• Referrer-Policy: Control referrer information leakage
• Rate Limiting: Protect against brute force and DDoS at the edge

# Define rate limit zone (10 req/s per IP)
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

server {
    # Apply global security headers
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    
    # Apply rate limiting to sensitive endpoints
    location /api/auth/login {
        limit_req zone=api_limit burst=5 nodelay;
        proxy_pass http://backend;
    }
}

If you are auditing an existing deployment, checking these proxy-level security controls is often the fastest win. My technical SEO audit guide includes security header validation because misconfigurations here directly impact both rankings and user trust.

How Do You Optimize Nginx Performance and Troubleshoot Common Issues?

Performance tuning separates functional proxies from production-grade ones. Default Nginx settings assume minimal load. Under real traffic, insufficient buffers, disabled compression, and missing cache layers cause latency spikes and increased backend costs. For businesses operating on tight margins, optimizing the proxy layer often delivers better ROI than vertical server scaling.

Compression and Caching Strategies

Gzip compression should be enabled selectively. Compressing already-compressed formats like JPEG or PNG wastes CPU cycles. Focus on text-based payloads where compression ratios exceed 70%. For Laravel APIs returning JSON, this dramatically reduces bandwidth costs on metered connections common in Nepal hosting environments.

gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_min_length 256;

# Only compress beneficial types
gzip_types 
    text/plain
    text/css
    text/xml
    text/javascript
    application/json
    application/javascript
    application/xml
    application/rss+xml
    image/svg+xml;

Debugging 502 and 504 Errors

The dreaded 502 Bad Gateway almost always indicates a communication failure between Nginx and the backend. Before blaming the application code, verify these three items in order:

1. Socket/Port Availability: Confirm the backend process is running and bound to the expected address using ss -tlnp | grep 8000 or ls -la /run/php/php8.4-fpm.sock.
2. Permission Mismatches: On Ubuntu, PHP-FPM sockets often run as www-data while Nginx runs as nginx. Ensure socket permissions allow read/write access or adjust the FPM pool configuration.
3. Timeout Values: If requests legitimately take longer than 60 seconds (report generation, file processing), increase proxy_read_timeout accordingly. The default is too conservative for many business applications.

For teams managing complex deployments, automating these health checks prevents downtime. My article on DevOps automation in Nepal covers integrating Nginx health monitoring into CI/CD pipelines so configuration drift gets caught before it reaches production.

Conclusion

Learning to set up a reverse proxy with Nginx correctly pays dividends across every project you deploy. The combination of SSL termination, header preservation, static asset offloading, and security enforcement creates a foundation that lets your application code remain simple and focused. Start with the base configurations provided here, validate headers with tools like curl or browser devtools, and incrementally add caching and rate limiting as traffic demands grow.

If you need hands-on assistance configuring Nginx for a Laravel, Node.js, or PHP production environment, reach out through my contact page. I regularly help teams in Nepal and internationally diagnose proxy issues, optimize performance, and establish deployment workflows that prevent configuration drift.