uWSGI配置文件中http与socket的差异及适用场景

Great question—this is a super common point of confusion when getting started with uWSGI and Nginx, and your test results actually perfectly illustrate the core differences between these two parameters.

Core Definitions #

First, the big distinction comes down to what protocol uWSGI uses to communicate on that port:

• http=127.0.0.1:8001: Turns uWSGI into a full-fledged HTTP server. It understands and speaks standard HTTP directly to clients (like your browser or curl).
• socket=127.0.0.1:8001: Configures uWSGI to use the uWSGI protocol—a lightweight, binary protocol built specifically for communication between uWSGI and reverse proxies (like Nginx). It’s way more efficient than HTTP, but regular HTTP clients (browsers) can’t understand it.

Why You Saw Those Errors #

Let’s tie this directly to your tests:

1. Error when using socket alone: When you tried to access uWSGI directly via a browser, your browser sent an HTTP request (e.g., GET / HTTP/1.1). But uWSGI was listening for uWSGI protocol traffic, so it misinterpreted the HTTP headers as an invalid block size (hence the invalid request block size: 21573 error)—it literally couldn’t parse what your browser was sending.
2. Timeout when using http with Nginx: Your Nginx config uses uwsgi_pass and includes uwsgi_params, which tells Nginx to send traffic to uWSGI using the uWSGI protocol. But if uWSGI is set to http, it’s waiting for HTTP requests, not uWSGI protocol traffic. The two services are speaking different languages, so Nginx waits for a response that never comes, leading to a timeout.

When to Use Each Parameter #

Use http when: #

• You’re in development/testing mode: Skip setting up Nginx entirely and run uWSGI as a standalone HTTP server to quickly validate your Django app. Just flip to http=127.0.0.1:8001 in your app.ini and visit the URL directly.
• You have a small, low-traffic app where you don’t need Nginx’s advanced features (like static file serving, SSL termination, load balancing, or complex request routing).

Use socket when: #

• You’re running a production setup with Nginx: This is the standard, high-performance setup. Nginx handles all client-facing work (serving static files, managing SSL, handling traffic spikes), then forwards dynamic requests to uWSGI via the efficient uWSGI protocol. Your current app.ini and Nginx config are set up correctly for this scenario—keep using socket=127.0.0.1:8001 here.
• You need to scale with multiple uWSGI instances: Reverse proxies like Nginx can distribute traffic across multiple uWSGI workers using the uWSGI protocol, which isn’t possible if uWSGI is running in HTTP mode.

Quick Recap #

• Direct client → uWSGI: Use http
• Client → Nginx → uWSGI: Use socket

内容的提问来源于stack exchange，提问作者Jinsu