When setting up a reverse proxy for Ruby web applications (particularly non-Rails apps using Thin server), the choice between Nginx and Apache involves multiple technical considerations. Let's break down the key differences from an operational perspective.

Nginx: Uses an event-driven architecture that handles thousands of concurrent connections with minimal memory footprint. In benchmarks with Thin:

# Sample Nginx config for Thin
upstream thin_cluster {
  server unix:/tmp/thin.0.sock;
  server unix:/tmp/thin.1.sock;
}

server {
  listen 80;
  location / {
    proxy_pass http://thin_cluster;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

Apache: Uses process-based threading (prefork MPM) which consumes more memory but offers better compatibility with certain modules:

# Sample Apache config for Thin
<VirtualHost *:80>
  ProxyPass / http://unix:/tmp/thin.0.sock|http://unix:/tmp/thin.1.sock
  ProxyPassReverse / http://unix:/tmp/thin.0.sock|http://unix:/tmp/thin.1.sock
</VirtualHost>

Nginx uses a declarative configuration syntax that's more compact but requires learning its specific directives. Apache's .htaccess files allow per-directory configuration without server restarts - useful for shared hosting environments.

While Apache has more historical documentation, Nginx's ecosystem has matured significantly. For Ruby-specific setups:

• Nginx: 83% of Ruby deployment guides reference Nginx
• Apache: Stronger support for legacy systems and complex authentication scenarios

For VPS environments running Ruby/Thin applications, Nginx generally provides:

• 30-40% better request throughput in benchmarks
• Lower memory usage (critical for small VPS instances)
• More modern load balancing features

The exception would be if you require specific Apache modules like mod_security for WAF capabilities or complex LDAP integration.

Here's a production-grade Nginx setup with caching and health checks:

upstream thin_app {
  least_conn;
  server unix:/tmp/thin.0.sock fail_timeout=5s;
  server unix:/tmp/thin.1.sock fail_timeout=5s;
  
  keepalive 32;
}

server {
  proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=thin_cache:10m inactive=60m;

  location / {
    proxy_cache thin_cache;
    proxy_pass http://thin_app;
    proxy_next_upstream error timeout http_500;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
  }
}

When implementing a reverse proxy for Ruby applications (particularly non-Rails stacks using Thin), the underlying architecture makes a significant difference:

# Nginx event-driven architecture example
events {
    worker_connections 1024;  # Handles thousands of connections per worker
}

# Apache prefork MPM example (traditional)

    StartServers       5
    MinSpareServers    5
    MaxSpareServers   10
    MaxClients       150  # Limited by RAM per process

Testing on a 2GB RAM VPS with Ruby/Thin backend:

For Ruby Thin applications, the proxy configuration differs significantly:

# Nginx reverse proxy config for Thin
upstream thin_cluster {
    server 127.0.0.1:3000;
    server 127.0.0.1:3001;
}

server {
    location / {
        proxy_pass http://thin_cluster;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

# Apache reverse proxy config for Thin

    ProxyPass / http://localhost:3000/
    ProxyPassReverse / http://localhost:3000/
    ProxyPreserveHost On

When dealing with WebSocket connections (common in modern Ruby apps):

# Nginx WebSocket support
location /socket {
    proxy_pass http://thin_cluster;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

# Apache WebSocket requires mod_proxy_wstunnel
ProxyPass /socket ws://localhost:3000/socket
ProxyPassReverse /socket ws://localhost:3000/socket

For zero-downtime deployments with Ruby applications:

# Nginx graceful reload
sudo nginx -s reload  # Works without dropping connections

# Apache graceful restart
sudo apachectl graceful  # May still drop some keep-alive connections

The memory efficiency of Nginx becomes particularly important when running multiple Ruby processes on memory-constrained VPS instances. Each Thin worker typically consumes 50-300MB RAM, leaving less room for the proxy itself.