添加 Microsoft 仓库

sudo rpm -Uvh https://packages.microsoft.com/config/centos/8/packages-microsoft-prod.rpm

安装运行时

sudo dnf install -y aspnetcore-runtime-8.0

验证

dotnet –list-runtimes

如果上面的源不可用，可以用脚本安装：

下载安装脚本

curl -sSL https://dot.net/v1/dotnet-install.sh -o dotnet-install.sh
chmod +x dotnet-install.sh

安装到 /usr/share/dotnet（全局）

sudo ./dotnet-install.sh –channel 8.0 –runtime aspnetcore –install-dir /usr/share/dotnet

创建软链接

sudo ln -sf /usr/share/dotnet/dotnet /usr/bin/dotnet

验证

dotnet –list-runtimes

本文是一次完整的 线上问题排查 + 架构修复 + 压力测试验证 的工程级总结，可作为 事故复盘、容量评估报告、运维 Runbook 使用。

一、问题背景与现象

初始问题

• Nginx 错误日志频繁出现：

  upstream timed out (110: Connection timed out) while connecting to upstream

• 请求多为：

  OPTIONS /api/Ads/resolve HTTP/2.0

• 上游地址：<code>127.0.0.1:5085</code>（.NET Kestrel）

同时观测到的内核异常

• <code>listen queue overflow</code>
• <code>SYNs to LISTEN sockets dropped</code>
• <code>SYN cookies sent</code>
• <code>TCPTimeWaitOverflow</code>

直接影响

• Nginx 无法连接本机上游
• API 出现大量失败
• 高并发下服务不可用

二、根因分析（结论级）

1⃣ Nginx → Kestrel 连接模型错误（核心根因）

在 <code>location /</code> 中错误地配置了：

proxy_set_header Connection "upgrade";

导致：

• 所有普通 HTTP 请求被迫使用 <code>Connection: upgrade</code>
• Keepalive 失效
• 每个请求都建立/断开 TCP 连接

直接引发短连接风暴

2⃣ OPTIONS 预检请求被放大

• 外站（如豆瓣）触发大量跨域请求
• 每个请求都会先发 <code>OPTIONS</code>
• <code>OPTIONS</code> 被转发到上游应用

在短连接模型下形成 连接洪峰。

3⃣ 内核层连锁反应

• SYN backlog 被打满
• accept queue 溢出
• 内核开始丢 SYN / 启用 SYN cookies
• Nginx 连接上游直接超时（110）

三、关键修复措施（工程级）

1⃣ 引入 upstream keepalive（最关键修复）

在 <code>http {}</code> 作用域中新增：

upstream eaglex_upstream {
    server 127.0.0.1:5085;
    keepalive 256;
}

统一使用：

proxy_pass http://eaglex_upstream;
proxy_http_version 1.1;
proxy_set_header Connection "";

2⃣ 修正 Connection 头使用方式（非常关键）

• 禁止在普通 HTTP 路径中使用：

  Connection: upgrade

• 只在 WebSocket 专用 location 中使用 upgrade

3⃣ 在 Nginx 层直接短路 OPTIONS 预检

location = /api/Ads/resolve {
    if ($request_method = OPTIONS) {
        add_header Access-Control-Allow-Origin $http_origin always;
        add_header Access-Control-Allow-Methods "GET,POST,OPTIONS" always;
        add_header Access-Control-Allow-Headers "Content-Type,Authorization" always;
        add_header Access-Control-Max-Age 86400 always;
        return 204;
    }
    proxy_pass http://eaglex_upstream;
}

彻底消除预检请求对上游的压力放大

4⃣ 缩短 proxy_connect_timeout（防止雪崩）

proxy_connect_timeout 2s;

避免 Nginx worker 在连接失败时长时间阻塞。

四、压测阶段的验证结论

压测过程中观测到的健康状态

• <code>.NET</code> CPU：≈ 260%–300%（4C 机器，尚有余量）
• Nginx CPU：≈ 10%–20%
• <code>ksoftirqd</code>：极低

• TCP 状态：

  estab ≈ 3000
  timewait ≈ 30
  orphan = 0

• 内核累计计数在压测前后 完全无增长：

  • listen queue overflow
  • SYN dropped
  • TCPTimeWaitOverflow

明确结论

连接层 / Nginx / 内核 TCP 已完全稳定，系统瓶颈成功转移至 .NET 应用 CPU 层。

五、错误日志的两类问题区分（重要）

A. <code>110 Connection timed out</code>

while connecting to upstream

• 含义：连接队列 / accept / backlog 问题
• 根因：连接模型错误
• 已在本次修复中解决

B. <code>111 Connection refused</code>

connect() failed (111: Connection refused)

• 含义：上游端口当时 没有进程在监听

• 可能原因：

  • dotnet 进程崩溃
  • 被 OOM killer 杀死
  • 重启 / 发布

属于 上游进程稳定性问题，与 backlog 无关。

六、压测与日常排障常用监控命令清单

1⃣ TCP 全局状态（必看）

ss -s

关注：<code>estab / timewait / orphan</code>

2⃣ 上游端口连接数（Nginx → Kestrel）

ss -ant | awk '$4=="127.0.0.1:5085"{c++} END{print c}'

3⃣ 上游连接状态分布

ss -ant | awk '$4=="127.0.0.1:5085"{print $1}' | sort | uniq -c | sort -nr

4⃣ 内核是否再次被打爆（差分判断）

netstat -s | egrep -i 'listen queue|SYNs to LISTEN|SYN cookies|TCPTimeWaitOverflow'

必须用 前后对比 判断是否仍在发生。

5⃣ Nginx 错误日志关键字

tail -n 200 /www/wwwlogs/eaglex_ads_api.error.log | egrep -i 'timed out|refused|502|504'

6⃣ 上游进程是否存活 / 是否重启

ps -p <dotnet_pid> -o pid,etimes,%cpu,%mem,cmd
ss -lntp | grep 5085

7⃣ OOM / 内核杀进程检查

dmesg -T | egrep -i 'oom|killed process'
journalctl -k | egrep -i 'oom|killed'

8⃣ .NET 运行时指标（强烈推荐）

dotnet-counters monitor System.Runtime --process-id <pid>

关注：

• CPU Usage
• ThreadPool Queue Length
• % Time in GC

七、最终工程级结论（可直接写入文档）

本次问题的根因是 Nginx → Kestrel 连接模型错误（短连接 + OPTIONS 预检放大），导致 TCP listen queue 溢出与 upstream connect timeout。

通过引入 upstream keepalive、修正 Connection 头、在 Nginx 层短路 CORS 预检，并配合合理的超时配置，连接层问题已完全消除。

压测结果表明：系统当前瓶颈已转移至 .NET 应用 CPU 层，TCP 与代理层稳定可靠，具备可预测的容量上限。