Nginx 大文件上传返回 413:从限制链路定位到安全放行的排查实践
## 适用场景 业务通过 Nginx 上传图片、安装包、备份文件或导入数据时,小文件正常,大文件刚提交便收到 `413 Request Entity Too Large`。应用日志没有请求记录,客户端通常只看到一个 Nginx 错误页。 本文以“上传 80 MB 压缩包失败、10 MB 图片正常”为例,说明怎样确认
Category
当前分类下的文章。
## 适用场景 业务通过 Nginx 上传图片、安装包、备份文件或导入数据时,小文件正常,大文件刚提交便收到 `413 Request Entity Too Large`。应用日志没有请求记录,客户端通常只看到一个 Nginx 错误页。 本文以“上传 80 MB 压缩包失败、10 MB 图片正常”为例,说明怎样确认
## 适用场景 本文适用于 MySQL 8.0 或已启用 GTID 的 MySQL 5.7 主从/主备架构:监控显示 `Seconds_Behind_Source` 持续增长,报表、读库或故障切换的恢复点开始不可接受。目标是先确认延迟真实原因,再在不破坏复制一致性的前提下恢复追平。 ## 现象描述 一次订单促销后
## 适用场景 业务服务部署在负载均衡、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 仍可能被复制从库、增量备份或审计流程使用。 本文适用
## 适用场景 Java、Django、Node.js 等服务在 Kubernetes 中滚动发布后,新 Pod 长时间处于 `CrashLoopBackOff`,Deployment 一直无法完成;而在开发或低负载环境中启动正常。日志常只来得及打印数据库连接、缓存预热或迁移检查的前几行。 本文以“应用冷启动约 9
## 适用场景 Docker 默认使用 `json-file` 日志驱动。运行一段时间后,宿主机 `/var/lib/docker` 持续变大,最终出现磁盘告警,甚至应用写文件、创建临时目录或重启容器都失败。本文适用于单机 Docker、Docker Compose 以及未由集中日志系统完全接管容器标准输出的场景。
## 适用场景 业务使用 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