Nginx 大文件上传返回 413：从限制链路定位到安全放行的排查实践
## 适用场景 业务通过 Nginx 上传图片、安装包、备份文件或导入数据时，小文件正常，大文件刚提交便收到 `413 Request Entity Too Large`。应用日志没有请求记录，客户端通常只看到一个 Nginx 错误页。 本文以“上传 80 MB 压缩包失败、10 MB 图片正常”为例，说明怎样确认
Tag
#Nginx
包含这个标签的文章。
Nginx 反向代理后客户端 IP 全变内网地址：从 realip 配置到防伪造的排查实践
## 适用场景 业务服务部署在负载均衡、CDN、Kubernetes Ingress 或四层代理之后。应用日志中的 `remote_addr` 全是代理的内网地址，限流、风控和审计都无法识别真实访问者；更危险的是，直接信任请求携带的 `X-Forwarded-For`，会让攻击者伪造来源 IP 绕过白名单。 本文以
Nginx 间歇性 502：upstream keepalive 陈旧连接的排查与治理实践
# Nginx 偶发 502 且上游日志正常：upstream keepalive 陈旧连接的排查与治理 ## 适用场景 服务部署在 Nginx 反向代理之后，流量高峰或发布后偶发 `502 Bad Gateway`。Nginx 错误日志出现 `upstream prematurely closed connect
Nginx upstream timed out 导致 504 的排查与治理实践
## 适用场景 本文适用于 Nginx 作为反向代理或网关时，用户访问接口偶发或持续返回 `504 Gateway Time-out`，错误日志中出现 `upstream timed out`、`while reading response header from upstream` 等信息的场景。 典型架构如下：
Filebeat 采集 Nginx 日志延迟和断点的排查实践
## 适用场景 这篇文章适用于 Nginx 接入 Filebeat、Logstash、Elasticsearch 或其他日志平台后，出现下面几类问题的场景： - Nginx 访问日志本地已经写入，但日志平台几分钟后才看到。 - 部分时间段日志缺失，业务同学按 trace id 或客户端 IP 查不到请求。 - 日志
Nginx 502、504、499 常见原因和排查思路
## 适用场景 线上服务通过 Nginx 反向代理访问，业务侧反馈接口偶发失败、页面加载慢，Nginx 访问日志里出现大量 `502`、`504` 或 `499` 状态码。 这类问题很常见，但三个状态码代表的方向并不一样： - `502 Bad Gateway`：Nginx 作为网关访问上游失败，通常是上游服务异
ingress 中添加proxy-connect-timeout 超时时间不生效
在ingress注释中添加以下配置一直没有生效的状态 ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/proxy-connect-timeout
Ingress Nginx 添加 basic auth 认证
#### 创建认证文件 通过htpasswd工具生成用户密码文件 ``` # htpasswd是apache httpd工具包中的工具 # 安装htpasswd ## centos yum install httpd-tools -y ## ubuntu sudo apt-get install apache2-u
Kubernetes扩容master(二进制)
目录 [TOC] [Kubernetes单master架构部署(二进制)](https://www.ywcsb.vip/blog/119.html) # 一、高可用架构（扩容多Master架构） Kubernetes作为容器集群系统，通过健康检查+重启策略实现了Pod故障自我修复能力，通过调度算法实现将Pod分
Nginx性能优化
### Nginx运行工作进程数量 Nginx运行工作进程个数一般设置CPU的核心或者核心数x2。如果不了解cpu的核数，可以top命令之后按1看出来，也可以查看/proc/cpuinfo文件 grep ^processor /proc/cpuinfo | wc -l。 ``` [root@lx~]# vi/usr/l