Nginx中send_timeout的作用、高低设置优劣及与keepalive_timeout的区别

Alright, let's break down your questions about Nginx's send_timeout directive clearly—no jargon overload, just straight, practical answers.

At its core, send_timeout controls how long Nginx will wait between two consecutive chunks of data being sent to the client before closing the connection. It’s not a limit on the total time for the entire response to be sent—just the gap between sending bits of data.

For example: If Nginx is streaming a large video file to a user, and their internet cuts out temporarily, Nginx will wait send_timeout seconds for the user to start receiving data again. If that window passes without any activity, Nginx drops the connection to free up resources.

Let’s weigh the tradeoffs for each value:

10s (Low Value) #

Pros: #

• Fast resource recovery: Stuck or unresponsive client connections get cleaned up quickly, freeing up worker processes and socket resources. This is a big win for high-traffic servers where every connection counts.
• Reduced unnecessary load: You won’t waste server resources holding onto connections that are effectively dead (e.g., a user’s browser crashed mid-download).

Cons: #

• Risk of interrupting legitimate slow connections: Users on spotty mobile networks or with high-latency connections might have gaps in data reception longer than 10s, leading to unexpected connection drops and failed requests/downloads.
• Bad for large file transfers: If a user is downloading a big file and their network hiccups for 12s, Nginx will kill the connection, forcing them to restart the download.

60s (High Value) #

Pros: #

• Better user experience for slow connections: Mobile users, rural internet users, or anyone downloading large assets (like videos, installers) will have more leeway for network fluctuations without getting disconnected.
• Fewer reconnections: Clients don’t have to repeatedly re-establish TCP connections (which adds overhead for both server and client) if they have brief lulls in activity.

Cons: #

• Increased resource overhead: If many clients end up stuck (e.g., a botnet with half-open connections), Nginx will hold those connections open for 60s, consuming more memory and socket slots. In extreme cases, this could prevent new legitimate connections from being processed.
• Slower cleanup of dead connections: You’ll have to wait longer for Nginx to realize a client is gone and free up its resources.

This is a common point of confusion—here’s the key distinction:

• send_timeout: Only applies during the active response-sending phase. It’s about waiting for the client to receive data while Nginx is actively pushing a response.
• keepalive_timeout: Applies during the idle phase of a persistent connection. After Nginx has sent a full response, this directive controls how long it keeps the connection open waiting for the client to send another request (avoiding the cost of re-establishing a TCP connection for every single request).

Example scenarios:

1. A user downloads a large file, and their connection freezes mid-transfer: send_timeout determines how long Nginx waits before cutting the connection.
2. A user loads a webpage, then sits on it for 30s without clicking anything: keepalive_timeout determines if Nginx still keeps that connection open when they finally click a link 30s later.

Hope that clears up all your questions!

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