Nginx 大文件上传返回 413:从限制链路定位到安全放行的排查实践
## 适用场景 业务通过 Nginx 上传图片、安装包、备份文件或导入数据时,小文件正常,大文件刚提交便收到 `413 Request Entity Too Large`。应用日志没有请求记录,客户端通常只看到一个 Nginx 错误页。 本文以“上传 80 MB 压缩包失败、10 MB 图片正常”为例,说明怎样确认
Tag
包含这个标签的文章。
## 适用场景 业务通过 Nginx 上传图片、安装包、备份文件或导入数据时,小文件正常,大文件刚提交便收到 `413 Request Entity Too Large`。应用日志没有请求记录,客户端通常只看到一个 Nginx 错误页。 本文以“上传 80 MB 压缩包失败、10 MB 图片正常”为例,说明怎样确认
## 适用场景 业务服务部署在负载均衡、CDN、Kubernetes Ingress 或四层代理之后。应用日志中的 `remote_addr` 全是代理的内网地址,限流、风控和审计都无法识别真实访问者;更危险的是,直接信任请求携带的 `X-Forwarded-For`,会让攻击者伪造来源 IP 绕过白名单。 本文以
## 适用场景 适用于运行在 Linux 虚拟机、物理机或容器节点上的 Web 服务。业务表现为同一版本在部分机器上间歇出现登录失效、JWT `token is not active` / `token expired`、HTTPS 握手失败或调用云 API 返回签名过期;重试、重启应用有时短暂恢复,但问题会再次出现
## 适用场景 MySQL 主库所在分区持续增长,`/var/lib/mysql` 已接近 100%,业务开始出现写入失败、事务提交变慢,甚至因为磁盘写满而触发只读保护。检查目录后发现大量 `mysql-bin.000xxx` 文件,但不能直接删除:binlog 仍可能被复制从库、增量备份或审计流程使用。 本文适用
## 适用场景 Docker 默认使用 `json-file` 日志驱动。运行一段时间后,宿主机 `/var/lib/docker` 持续变大,最终出现磁盘告警,甚至应用写文件、创建临时目录或重启容器都失败。本文适用于单机 Docker、Docker Compose 以及未由集中日志系统完全接管容器标准输出的场景。
## 适用场景 业务运行在 Linux 主机、Docker 或 Kubernetes 节点上,经过 NAT、iptables/nftables 防火墙或四层负载均衡转发。某个时段开始出现 API 偶发超时、DNS 请求失败、容器无法访问外部服务,但主机 CPU、内存和带宽看起来都正常;重启网络或重启节点后短暂恢复。
## 适用场景 业务使用 Redis 承载登录态、商品详情、计数器或排行榜。平时接口稳定,但在促销、定时任务或某些请求集中到来时,应用开始出现 Redis 超时;监控中 `instantaneous_ops_per_sec` 并不一定很高,CPU 也可能没有持续满载。 本文以单实例或主从架构为例,说明如何区分 **
## 适用场景 集群中的应用偶发报出 `lookup xxx on 10.96.0.10:53: i/o timeout`、`SERVFAIL` 或连接外部服务失败;重试后又恢复。故障通常集中在业务高峰,Pod 重建、扩容或切换节点后更明显。本文适用于使用 CoreDNS 作为集群 DNS,且 CoreDNS 需要转
# Nginx 偶发 502 且上游日志正常:upstream keepalive 陈旧连接的排查与治理 ## 适用场景 服务部署在 Nginx 反向代理之后,流量高峰或发布后偶发 `502 Bad Gateway`。Nginx 错误日志出现 `upstream prematurely closed connect
## 适用场景 服务容器偶发或持续重启,`docker ps -a` 显示退出码为 `137`,应用日志末尾没有 Java、Python 或 Go 自己抛出的异常。宿主机看起来还有可用内存,但容器仍被杀掉;或者一次流量高峰后多个容器同时不可用。 本文以 Docker / Docker Compose 部署的 API