When working with Nginx as a reverse proxy during local development, you might encounter this frustrating scenario:

server {
  listen 80;
  server_name myvirtualhost1.local;
  location / {
    proxy_pass http://127.0.0.1:8080;
  }
}

Everything works fine until you need to debug your backend application. The moment your debugging session exceeds 30 seconds, Nginx abruptly terminates the connection with a 504 Gateway Time-out error.

Nginx has several timeout-related directives that control proxy behavior:

• proxy_connect_timeout (default: 60s)
• proxy_send_timeout (default: 60s)
• proxy_read_timeout (default: 60s)

Despite these defaults, many Linux distributions set lower values in their default configurations. The 30-second timeout you're experiencing is likely coming from the fastcgi_read_timeout or similar directives.

For local development environments where you need indefinite waiting, add these directives to your nginx.conf in the http context:

http {
  proxy_connect_timeout 600;
  proxy_send_timeout 600;
  proxy_read_timeout 600;
  send_timeout 600;
  
  # For PHP-FPM setups
  fastcgi_connect_timeout 600;
  fastcgi_send_timeout 600;
  fastcgi_read_timeout 600;
}

The value 600 (10 minutes) gives you ample debugging time. For truly infinite timeouts during development, you can set these to the maximum value:

proxy_read_timeout 0;
proxy_send_timeout 0;

If you prefer to keep global timeouts reasonable but need extended timeouts for specific services:

server {
  listen 80;
  server_name debug.local;
  
  location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_read_timeout 3600; # 1 hour
    proxy_send_timeout 3600;
  }
}

When running Nginx in Docker containers for development, you need additional configuration:

server {
  listen 80;
  
  location / {
    proxy_pass http://backend:3000;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_read_timeout 0;
  }
}

After making changes, always test your configuration:

nginx -t # Test configuration
nginx -s reload # Reload if test passes

You can simulate long-running requests using curl:

curl -v http://myvirtualhost1.local/slow-endpoint

Remember that these settings should never be used in production environments. They're strictly for development purposes where you need extended debugging sessions.

When debugging applications behind an Nginx reverse proxy, you'll often encounter the dreaded 504 Gateway Time-out after 30 seconds. This default timeout behavior interrupts debugging sessions where you might pause execution for inspection.

Nginx has several timeout-related directives that affect proxy behavior:

• proxy_read_timeout: Time between two successive read operations
• proxy_connect_timeout: Connection timeout to upstream
• proxy_send_timeout: Time between two successive write operations

For local development, you can disable timeouts entirely by setting them to 0 in the http context (affects all proxy locations):

http {
    proxy_read_timeout 0;
    proxy_connect_timeout 0;
    proxy_send_timeout 0;
    
    server {
        listen 80;
        server_name myvirtualhost1.local;
        location / {
            proxy_pass http://127.0.0.1:8080;
        }
    }

    server {
        listen 80;
        server_name myvirtualhost2.local;
        location / {
            proxy_pass http://127.0.0.1:9090;
        }
    }
}

If you prefer to keep some timeouts but extend them significantly:

server {
    listen 80;
    server_name myvirtualhost1.local;
    
    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_read_timeout 24h;
        proxy_connect_timeout 600s;
        keepalive_timeout 24h;
    }
}

After making changes, verify they're working with:

nginx -t
systemctl reload nginx

Then test using a simple endpoint that sleeps longer than the previous timeout period.

While useful for development, never use these timeout settings in production. They make your server vulnerable to denial-of-service attacks. Instead, consider:

• Using proper debugging tools
• Setting reasonable high values (e.g., 10-15 minutes)
• Implementing proper request cancellation