惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Engineering at Meta
Engineering at Meta
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
小众软件
小众软件
博客园_首页
T
Tailwind CSS Blog
美团技术团队
博客园 - 叶小钗
Microsoft Security Blog
Microsoft Security Blog
有赞技术团队
有赞技术团队
Apple Machine Learning Research
Apple Machine Learning Research
大猫的无限游戏
大猫的无限游戏
Microsoft Azure Blog
Microsoft Azure Blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
I
InfoQ
MongoDB | Blog
MongoDB | Blog
The Cloudflare Blog
J
Java Code Geeks
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
博客园 - 聂微东
酷 壳 – CoolShell
酷 壳 – CoolShell
Blog — PlanetScale
Blog — PlanetScale
IT之家
IT之家
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Y
Y Combinator Blog

NGINX Community Blog

HTTP Strict Transport Security Policy in NGINX Ingress Controller Predicate Routing for Native Handling of API Traffic – NGINX Community Blog Gateway API 1.6 conformance, external authentication, and fewer snippets – NGINX Community Blog HSTS without snippets, a faster start on large clusters, and improved configuration safety – NGINX Community Blog Control API, predicate locations, early body inspection, and more – NGINX Community Blog PROXY Protocol v2, Stricter Validation and More – NGINX Community Blog External Authentication Policy in NGINX Ingress Controller: A Real World Use Case – NGINX Community Blog External Authentication Policy in NGINX Ingress Controller: Patterns for VirtualServer and Ingress – NGINX Community Blog mTLS Policies in NGINX Ingress Controller – NGINX Community Blog Optimising NGINX Ingress Controller Startup Performance – NGINX Community Blog Meet With Us: NGINX Gateway Fabric & NGINX Ingress Controller Community Calls  – NGINX Community Blog Security, Performance, and Easier Migration – NGINX Community Blog Strengthening the NGINX Community – NGINX Community Blog F5 WAF for NGINX Comes to the Gateway API – NGINX Community Blog How NGINX Ingress Controller and NGINX Gateway Fabric Handle Kubernetes Backend Changes Natively – NGINX Community Blog Cache Policy in NGINX Ingress Controller: A Practical Guide for VirtualServer – NGINX Community Blog Access Control Policy in NGINX Ingress Controller: Patterns for Ingress – NGINX Community Blog Enterprise-Grade Features and Gateway API 1.5 Conformance – NGINX Community Blog NGINX OSS 1.29.6 and 1.29.7: Open-sourced Session Persistence, Multipath TCP and More – NGINX Community Blog CORS Policy in NGINX Ingress Controller v5.4.0: Patterns for VirtualServer and Ingress – NGINX Community Blog A Community Hub for NGINX on Kubernetes, Including a New Ingress-NGINX Migration Tool – NGINX Community Blog
Keep-alive to upstreams is now default in NGINX 1.29.7 – ...
Nick Shadrin · 2026-03-24 · via NGINX Community Blog

Before version 1.29.7, NGINX used HTTP/1.0 by default for connecting to HTTP upstream servers. This older version of the protocol does not have the capability of HTTP persistent connections, commonly known as “keep-alive.”

Keep-alive reduces the number of handshakes, reduces latency, and reduces time to first byte for most regular web applications. In order to enable HTTP/1.1 and switch on the keep-alive behavior for upstream servers, operators added several directives in their configuration files. In many cases, this was forgotten, and multiple parts of web applications ended up working slower than expected.

Commonly used configuration snippet:

proxy_http_version 1.1;
proxy_set_header Connection "";

With version 1.29.7, released in March 2026, we changed the default behavior of HTTP proxying to use HTTP/1.1 with keep-alive.

The above-mentioned configuration lines are now no longer needed.

Downgrading upstream connections to HTTP/1.0

If your backend servers specifically require HTTP/1.0, you can use the following configuration lines in the relevant location contexts:

proxy_http_version 1.0;
proxy_set_header Connection "Close";

New keepalive directive parameter “local”

When the same upstream block is referenced across multiple locations or server blocks, requests from those different locations may be multiplexed over a single TCP connection to the upstream.

This behavior is controlled by the “local” parameter of the keepalive directive in the upstream context.

Due to backwards compatibility with previous NGINX versions, the default behavior of this parameter is not obvious. Please read through the following three options:

1. Default behavior when no keepalive directive is present: cached upstream connections are not shared between locations.

2. Behavior when the keepalive directive is present without the “local” parameter: cached upstream connections are shared between locations. This behavior is consistent with previous versions of NGINX:

upstream your-upstream-name {
  keepalive 32;
....
}

3. Behavior when the keepalive directive is present with the “local” parameter: this is the most explicit setting, with a predictable outcome.

upstream your-upstream-name {
  keepalive 32 local;
....
}

Refer to the official documentation for more details:

https://nginx.org/en/docs/http/ngx_http_proxy_module.html

https://nginx.org/en/docs/http/ngx_http_upstream_module.html

Use the “Discussions” section of our official repository for feedback: https://github.com/nginx/nginx/discussions

Follow the upcoming code changes and development conversations: https://github.com/nginx/nginx/pulls

NGINX Community Forum