TLS 证书链不完整导致部分客户端握手失败：从现场验证到无损修复
适用场景 本文适用于网站、API 网关或反向代理已经配置 HTTPS，但出现“浏览器能访问，部分 Java、Android、容器或命令行客户端却握手失败”的场景。典型报错包括 unable to get local issuer certificate、PKIX path building failed、certifi
Tag
#Nginx
包含这个标签的文章。
Nginx 大文件上传返回 413：从限制链路定位到安全放行的排查实践
适用场景 业务通过 Nginx 上传图片、安装包、备份文件或导入数据时，小文件正常，大文件刚提交便收到 413 Request Entity Too Large。应用日志没有请求记录，客户端通常只看到一个 Nginx 错误页。 本文以“上传 80 MB 压缩包失败、10 MB 图片正常”为例，说明怎样确认拦截层、放开正
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 connection、recv()
Nginx upstream timed out 导致 504 的排查与治理实践
适用场景 本文适用于 Nginx 作为反向代理或网关时，用户访问接口偶发或持续返回 504 Gateway Time-out，错误日志中出现 upstream timed out、while reading response header from upstream 等信息的场景。 典型架构如下： Client ->
Filebeat 采集 Nginx 日志延迟和断点的排查实践
适用场景 这篇文章适用于 Nginx 接入 Filebeat、Logstash、Elasticsearch 或其他日志平台后，出现下面几类问题的场景： Nginx 访问日志本地已经写入，但日志平台几分钟后才看到。 部分时间段日志缺失，业务同学按 trace id 或客户端 IP 查不到请求。 日志轮转后采集停止，重启
Nginx 502、504、499 常见原因和排查思路
适用场景 线上服务通过 Nginx 反向代理访问，业务侧反馈接口偶发失败、页面加载慢，Nginx 访问日志里出现大量 502、504 或 499 状态码。 这类问题很常见，但三个状态码代表的方向并不一样： 502 Bad Gateway：Nginx 作为网关访问上游失败，通常是上游服务异常、连接失败、协议异常。 504
ingress 中添加proxy-connect-timeout 超时时间不生效
在ingress注释中添加以下配置一直没有生效的状态 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/proxy-connect-timeout: '300s' nginx
Ingress Nginx 添加 basic auth 认证
创建认证文件 通过htpasswd工具生成用户密码文件 # htpasswd是apache httpd工具包中的工具 # 安装htpasswd ## centos yum install httpd-tools -y ## ubuntu sudo apt-get install apache2-utils -y # 创
Kubernetes扩容master(二进制)
目录 [TOC] Kubernetes单master架构部署(二进制) 一、高可用架构（扩容多Master架构） Kubernetes作为容器集群系统，通过健康检查+重启策略实现了Pod故障自我修复能力，通过调度算法实现将Pod分布式部署，并保持预期副本数，根据Node失效状态自动在其他Node拉起Pod，实现了应用层