Reverse Proxy – Why Use a Reverse Proxy in Front of a WSGI Server

httpnginxPROXYwsgi

A typical configuration for deploying a WSGI application includes a WSGI server (such as uWSGI or Gunicorn) behind a general-purpose web server (like nginx) that acts as a reverse proxy. One major reason I know for having a reverse proxy is to serve static files efficiently. Are there any other reasons?

Suppose my application involves only Python code and doesn’t care about static content. Why would I want the reverse proxy in this case? uWSGI and Gunicorn each already provide an asynchronous HTTP server capable of interfacing with the clients.

Are there any practical cases where I would be better off exposing the WSGI HTTP server directly to the outside world?

Best Answer

  • you have more config-options with a full-blown reverse - proxy like

    • rewrite
    • locations
    • server
    • https
    • header-cleanup
    • expires
    • gzip
    • ....
  • you can do loadbalancing

  • you can use proxy_cache
  • you can implement custom error-pages, even when your app-servers are down
  • you can have a WAF implemented
  • you can (sometimes) hotpatch against vulnerabilities

BONUSPOINT

  • you can impress clients with 100.000 requests/second (on average hardware) with the following setup (nginx):

.

location /perftest/ {
    return 200;
}