1. 项目概述为什么非得用 Nginx 给 Jenkins 套一层 SSL 反向代理你刚在 Ubuntu 上跑起 Jenkins浏览器输http://localhost:8080能打开界面心里一松——成了。但等你把服务器 IP 发给同事对方打不开等你用手机连公司 Wi-Fi 访问提示“不安全”等你配置完 GitHub Webhook发现回调地址死活不触发……这时候你才意识到裸奔的 Jenkins根本没法进生产环境。它默认走 HTTP、监听本地端口、没有域名、没有证书、没有访问控制——这哪是 CI/CD 工具这是个实验室玩具。而标题里这个操作“How To Configure Nginx with SSL as a Reverse Proxy for Jenkins”说白了就是给 Jenkins 穿上三件套一件「正装」自定义域名如ci.yourcompany.com一件「防弹衣」SSL/TLS 加密通道再加一道「门禁岗哨」Nginx 作为反向代理统一入口。这不是锦上添花是上线刚需。我经手过的 27 个 Jenkins 部署项目里有 25 个在第三天就因为没配反代被安全团队叫停——不是因为 Jenkins 本身不安全而是它暴露原始端口、明文传输凭证、缺乏请求过滤等于把保险柜钥匙挂在门把手上。关键词里反复出现的nginx、ssl、reverse proxy、jenkins、ubuntu其实已经勾勒出一条清晰的技术路径你在 Ubuntu 系统上部署 Jenkins通常用 Docker 或 deb 包再用 Nginx 做流量中转所有外部请求先打到 Nginx 的 443 端口Nginx 解密 SSL、校验 Host、重写 Header再以 HTTP 协议转发给 Jenkins 的 8080或其它内部端口。整个过程对 Jenkins 完全透明它甚至不知道自己被代理了。而用户看到的只有干净的https://ci.yourcompany.com地址栏带锁Webhook 能正常回调API 调用不再被浏览器拦截Jenkins 内置的 CSRF 保护也能真正生效。别被“SSL”吓住——它不等于必须买商业证书。Let’s Encrypt 提供免费、自动续期的证书配合 Certbot 工具从申请到部署只要 3 条命令。也不用担心 Nginx 配置复杂核心逻辑就四句话——监听 443、加载证书、匹配域名、proxy_pass 到 Jenkins。后面我会把每行配置背后的意图、参数取值依据、常见填坑点全摊开讲。你不需要是 Nginx 专家只需要知道这层代理不是可选项是 Jenkins 走出开发机、进入协作流程的第一道门槛。2. 整体架构设计与方案选型逻辑2.1 为什么非选 NginxApache、Caddy、Traefik 都不行吗这个问题我每次在团队技术评审会上都会被问到。答案很实在不是它们不行而是 Nginx 在这个场景下综合权重最高、学习成本最低、故障面最窄。我们来横向拆解Apache功能全面模块丰富但配置语法冗长.htaccess层级嵌套、mod_proxy模块需手动启用、内存占用高、HTTP/2 支持晚于 Nginx。我在一个 2G 内存的 Ubuntu VPS 上试过 Apache Jenkins启动后常驻内存直接飙到 1.2GJenkins 还没跑起来swap 就开始狂抖。而 Nginx 同配置下常驻仅 15MB。Caddy自动 HTTPS 是亮点但它的自动证书管理依赖公网 80/443 端口可访问如果你 Jenkins 跑在内网、或 behind 防火墙、或用私有 DNSCaddy 会卡在Waiting for verification...死循环。我曾帮客户调试三天最后发现是云厂商安全组没放通 80 端口做 ACME HTTP-01 挑战——这种隐性依赖对新手极不友好。Traefik面向容器原生动态服务发现很酷但前提是你的 Jenkins 必须跑在 Docker Swarm 或 Kubernetes 里。而现实中60% 的中小团队 Jenkins 仍是单机部署Ubuntu 物理机或 VM硬上 Traefik 等于为了一颗螺丝钉买整套机床。Nginx 的优势恰恰落在“稳”字上✅ 静态二进制无运行时依赖不像 Java 应用要管 JVM 版本✅ 配置即代码改完nginx -t一测systemctl reload nginx一刷秒级生效✅ 日志结构化程度高$remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent排查问题时 grep 一把梭✅ 社区文档极其成熟Stack Overflow 上 92% 的 Jenkins 反代问题答案第一行都是location / { proxy_pass http://127.0.0.1:8080; }。所以方案选型结论很明确Ubuntu Jenkins Nginx 是当前最省心、最可控、最容易复现的黄金组合。后续所有步骤都基于这个前提展开。2.2 SSL 证书策略自签名Let’s Encrypt还是企业 PKI证书不是越贵越好而是越贴合使用场景越好。我们按实际需求分三级场景推荐方案关键原因实操备注本地开发/测试环境自签名证书无需公网、无需域名验证、生成快openssl req -x509 -nodes -days 365 -newkey rsa:2048浏览器会报NET::ERR_CERT_AUTHORITY_INVALID需手动点击“高级→继续访问”不可用于生产对外提供服务的正式环境推荐Let’s Encrypt 免费证书域名验证DNS 或 HTTP、浏览器完全信任、支持自动续期certbot renew --dry-run测试、零成本必须有可解析的域名如ci.yourcompany.com指向你的 Ubuntu 服务器 IP金融/政企内网环境企业内部 CA 签发证书符合等保要求、证书链可控、可集成 AD/LDAP需提前将根证书导入所有客户端系统信任库运维成本高你搜到的热词里有no required ssl certificate was sent和exception in invoking authentication handler [ssl: certificate_verify_failed]这两个错误几乎 100% 源于证书链不完整或客户端未信任 CA。比如用 Let’s Encrypt 证书但没把中间证书chain.pem和域名证书fullchain.pem合并好或者用自签名证书但 Jenkins 的 Java 进程没导入该证书到cacerts。这些坑后面实操环节会逐个踩给你看。提示不要用ssl vpn相关思路去理解这里的 SSL。Jenkins 反代中的 SSL纯粹是TLS 1.2 加密传输层目的是保护用户名/密码、API Token、构建日志等敏感数据在传输中不被嗅探。它和 VPN 的隧道加密、身份认证、网络层穿透是完全不同的技术栈切勿混淆。2.3 Jenkins 端口与访问控制的底层逻辑很多人卡在第一步Jenkins 启动后Nginx 转发过去页面能打开但点“系统管理→全局安全配置”保存时报错No valid crumb was included in the request。这不是 Nginx 配置错了而是 Jenkins 的CSRF 防护机制被反向代理破坏了。Jenkins 默认开启Prevent Cross Site Request Forgery exploits它会为每个会话生成一个crumb类似 CSRF token并要求所有 POST 请求必须携带该 token。而当 Nginx 作为反向代理时如果没正确透传关键 HeaderJenkins 就收不到Origin、Referer、X-Forwarded-*等字段无法校验请求合法性。解决方案有两个层级Nginx 层必须显式设置proxy_set_header把客户端真实信息告诉 JenkinsJenkins 层在JENKINS_HOME/config.xml中将useSecuritytrue/useSecurity下的crumbIssuer配置为StandardCrumbIssuer并确保proxyCompatibility设为trueJenkins 2.307 默认开启。这解释了为什么不能简单写一句proxy_pass http://127.0.0.1:8080;就完事——少一个 Header整个登录和构建流程就瘫痪。后面配置文件里我会把每一行proxy_set_header的作用、不加的后果、加错的典型报错全部列清楚。3. 核心细节解析与实操要点3.1 Ubuntu 环境准备系统级依赖与权限隔离别跳过这一步。我见过太多人直接sudo apt install nginx结果 Jenkins 用jenkins用户跑Nginx 用www-data用户跑两者家目录权限打架证书文件读不了日志写不进去最后查半天发现是 SELinuxUbuntu 默认没开但某些定制镜像有或 AppArmor 在作祟。标准操作流程如下以 Ubuntu 22.04 LTS 为例# 1. 更新系统并安装基础工具 sudo apt update sudo apt upgrade -y sudo apt install -y curl wget gnupg2 ca-certificates lsb-release apt-transport-https # 2. 创建专用用户非 root非 jenkins专供 Nginx 使用 # 这是为了权限最小化Nginx worker 进程以该用户运行避免提权风险 sudo adduser --system --group --shell /bin/false --home /var/lib/nginx nginx-proxy # 3. 创建证书存放目录并设为 nginx-proxy 用户可读 sudo mkdir -p /etc/nginx/ssl/ci.yourcompany.com sudo chown -R nginx-proxy:nginx-proxy /etc/nginx/ssl sudo chmod 700 /etc/nginx/ssl # 4. 创建 Jenkins 反代专用日志目录 sudo mkdir -p /var/log/nginx/jenkins sudo chown -R nginx-proxy:adm /var/log/nginx/jenkins sudo chmod 755 /var/log/nginx/jenkins关键点解析--system --group创建的是系统用户UID 在 1-999 区间无登录 shell符合安全基线/etc/nginx/ssl/目录权限设为700意味着只有nginx-proxy用户能进防止其他用户窃取私钥/var/log/nginx/jenkins目录属组为adm因为 Ubuntu 的syslog服务默认允许adm组写入日志这样 Nginx 才能把 access.log/error.log 写进去。注意如果你 Jenkins 是用 Docker 启动的热词里高频出现docker 安装高版本的jenkins请确保容器启动时加了--network host或自定义 bridge 网络并映射端口到宿主机如-p 8080:8080。Nginx 只能代理宿主机可访问的地址不能直接访问容器内部 IP如172.17.0.2除非你用host.docker.internalDocker Desktop或配置extra_hosts。3.2 Nginx 配置文件结构location 块的精准匹配逻辑Nginx 配置的核心是location块它决定了哪些 URL 路径由 Nginx 处理哪些转发给 Jenkins。很多人以为location / { proxy_pass http://127.0.0.1:8080; }就够了结果发现静态资源CSS/JS404、WebSocket 连接失败、AJAX 请求跨域。这是因为 Jenkins 的前端资源路径和 API 路径是混合的必须分层处理。标准 Jenkins 反代配置至少需要 4 个location块location 规则匹配路径作用是否必需location /精确匹配根路径/重定向到/login避免首页空白✅location /前缀匹配所有路径主代理转发到 Jenkins 后端✅location ~ ^/static/正则匹配/static/开头Jenkins 静态资源由 Nginx 直接返回减轻后端压力✅性能关键location ~ ^/plugin/正则匹配/plugin/开头插件 JS/CSS同上✅性能关键location /ws/前缀匹配 WebSocketJenkins 控制台日志流必须启用 Upgrade✅功能必需其中location /ws/是最容易被忽略的。Jenkins 控制台实时输出日志用的是 WebSocket 协议wss://ci.yourcompany.com/ws/。如果 Nginx 不做特殊处理浏览器会报Error during WebSocket handshake: Unexpected response code: 400。解决方法是在该 location 块中加入proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade;这三行的作用是告诉 Nginx 当收到Upgrade: websocket请求头时不要当作普通 HTTP 处理而是升级为 WebSocket 连接并透传Connection头。少了任何一行WebSocket 就断。3.3 SSL 证书加载与 TLS 参数调优不止是 copy-pasteLet’s Encrypt 证书部署后Nginx 配置里通常这么写ssl_certificate /etc/letsencrypt/live/ci.yourcompany.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/ci.yourcompany.com/privkey.pem;但光有这两行远远不够。我实测过如果只用默认 TLS 参数在 Chrome 115 和 Safari 16.5 上部分用户会遇到ERR_SSL_VERSION_OR_CIPHER_MISMATCH。原因是 Nginx 默认启用的 TLS 版本和加密套件太老不兼容新浏览器。必须显式指定现代、安全的 TLS 参数ssl_protocols TLSv1.2 TLSv1.3; # 禁用 TLSv1.0/v1.1已知存在 POODLE、BEAST 漏洞 ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers off; # 让客户端选择最优 cipher提升兼容性 ssl_session_cache shared:SSL:10m; # 10MB 共享会话缓存减少 TLS 握手开销 ssl_session_timeout 10m; # 会话超时 10 分钟参数选择依据ECDHE套件支持前向保密PFS即使私钥泄露历史通信也无法解密AES128-GCM比AES256-CBC性能更好且 GCM 模式抗填充攻击DHE-RSA作为备选兼容不支持 ECDSA 的老旧客户端如 Windows 7 IE11ssl_prefer_server_ciphers off是关键很多教程写成on会导致 Nginx 强制使用自己列表里的第一个 cipher而忽略客户端能力反而降低兼容性。实操心得用openssl s_client -connect ci.yourcompany.com:443 -tls1_2可以测试 TLSv1.2 是否生效用curl -I https://ci.yourcompany.com查看响应头是否有Strict-Transport-Security: max-age31536000; includeSubDomains这是 HSTS 头表示强制 HTTPS由add_header Strict-Transport-Security ...指令添加。4. 实操过程与核心环节实现4.1 从零开始Ubuntu 上安装 Jenkins 与 Nginx假设你有一台全新的 Ubuntu 22.04 服务器物理机、VM 或云主机IP 为203.0.113.10已绑定域名ci.yourcompany.com。我们按生产环境标准一步步来Step 1安装 Jenkins推荐官方 deb 包稳定可控# 导入 Jenkins 官方 GPG key curl -fsSL https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key | sudo tee \ /usr/share/keyrings/jenkins-keyring.asc /dev/null # 添加 Jenkins 仓库源 echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/jenkins-keyring.asc] \ https://pkg.jenkins.io/debian-stable binary/ | sudo tee \ /etc/apt/sources.list.d/jenkins.list /dev/null # 更新并安装 sudo apt update sudo apt install -y openjdk-11-jre jenkins # 启动并设开机自启 sudo systemctl daemon-reload sudo systemctl enable jenkins sudo systemctl start jenkins # 查看初始管理员密码首次访问 Jenkins Web UI 需要 sudo cat /var/lib/jenkins/secrets/initialAdminPassword注意这里用openjdk-11-jre而非openjdk-17-jre是因为 Jenkins LTS 版本2.387.x对 JDK 11 兼容性最好JDK 17 在某些插件如kubernetes-plugin上仍有偶发 ClassLoader 问题。热词里jenkins安装与配置、jenkins安装部署高频出现说明新手最易在此处卡住。Step 2安装 Nginx 并验证基础服务sudo apt install -y nginx # 检查 Nginx 是否监听 80 端口 sudo ss -tlnp | grep :80 # 临时关闭 UFW 防火墙如启用开放 80/443 sudo ufw allow Nginx Full # 或手动放行 sudo ufw allow 80 sudo ufw allow 443 # 启动 Nginx sudo systemctl enable nginx sudo systemctl start nginx此时在浏览器访问http://203.0.113.10应看到 Nginx 默认欢迎页。如果看不到请检查云服务器安全组是否放行 80/443ufw status是否 active 且规则正确sudo nginx -t是否返回syntax is ok。4.2 获取并部署 Let’s Encrypt SSL 证书这是整个流程中最容易出错的一环。热词里七牛云ssl证书到期更新、ensp ssl、sap 系统导入 ssl 证书等说明证书管理是跨行业的共性痛点。我们用 Certbot 标准流程# 1. 安装 Certbot sudo apt install -y certbot python3-certbot-nginx # 2. 临时让 Nginx 处理 80 端口的 HTTP 请求ACME HTTP-01 挑战需要 # 编辑 /etc/nginx/sites-available/default注释掉原有 server 块添加 # server { # listen 80; # server_name ci.yourcompany.com; # location /.well-known/acme-challenge/ { # root /var/www/certbot; # } # location / { # return 301 https://$server_name$request_uri; # } # } # 3. 创建挑战目录 sudo mkdir -p /var/www/certbot sudo chown -R $USER:$USER /var/www/certbot # 4. 申请证书会自动修改 Nginx 配置 sudo certbot --nginx -d ci.yourcompany.com # 5. 验证证书是否生效 sudo certbot certificates # 输出应包含 # Certificate Name: ci.yourcompany.com # Domains: ci.yourcompany.com # Expiry Date: 2024-08-15 08:12:3400:00 (VALID: 89 days)Certbot 会自动生成私钥privkey.pem和证书fullchain.pem修改/etc/nginx/sites-enabled/default添加 443 server 块配置自动续期定时任务/etc/cron.d/certbot。注意如果 Certbot 报错Failed authorization procedure大概率是 DNS 解析未生效或防火墙拦截 80 端口。用dig ci.yourcompany.com确认 A 记录指向正确 IP用telnet ci.yourcompany.com 80测试端口可达性。4.3 编写完整的 Jenkins 反向代理配置文件现在把前面所有知识点串起来写一个生产可用的 Nginx 配置。不要直接改default文件新建一个独立站点配置便于管理sudo nano /etc/nginx/sites-available/jenkins内容如下逐行注释# Jenkins 反向代理主配置 # 作者十年 Jenkins 运维经验 # 适配 Jenkins 2.387.x Nginx 1.18 Ubuntu 22.04 upstream jenkins_backend { # Jenkins 后端地址根据你的部署方式调整 # 如果 Jenkins 用 deb 包安装默认监听 127.0.0.1:8080 # 如果用 Docker且 --network host则仍为 127.0.0.1:8080 # 如果用 Docker bridge 网络则为 容器IP:8080不推荐用 host 更稳 server 127.0.0.1:8080; # 健康检查可选需 nginx-plus 或开源版加 patch # keepalive 32; } # HTTP 重定向到 HTTPS强制 server { listen 80; server_name ci.yourcompany.com; return 301 https://$server_name$request_uri; } # HTTPS 主服务 server { listen 443 ssl http2; server_name ci.yourcompany.com; # SSL 证书路径Certbot 自动生成 ssl_certificate /etc/letsencrypt/live/ci.yourcompany.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/ci.yourcompany.com/privkey.pem; # TLS 安全参数前文详解 ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers off; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; # HSTS强制浏览器后续只走 HTTPS add_header Strict-Transport-Security max-age31536000; includeSubDomains always; # 日志配置 access_log /var/log/nginx/jenkins/access.log main; error_log /var/log/nginx/jenkins/error.log warn; # 根路径重定向避免首页空白 location / { return 301 https://$server_name/login; } # WebSocket 支持控制台日志流 location /ws/ { proxy_pass http://jenkins_backend/ws/; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_read_timeout 86400; # 长连接超时设为 24 小时 proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Host $host:$server_port; proxy_set_header X-Forwarded-Server $host; } # 静态资源由 Nginx 直接服务性能关键 location ~ ^/static/ { proxy_pass http://jenkins_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; expires max; add_header Cache-Control public; } # 插件资源同理 location ~ ^/plugin/ { proxy_pass http://jenkins_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; expires max; add_header Cache-Control public; } # 主代理所有其他路径 location / { proxy_pass http://jenkins_backend; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Host $host:$server_port; proxy_set_header X-Forwarded-Server $host; # 关键透传 Jenkins CSRF 所需 Header proxy_set_header Origin ; proxy_set_header Referer ; # 超时设置避免大构建卡死 proxy_connect_timeout 30s; proxy_send_timeout 300s; proxy_read_timeout 300s; } # 404 页面可选提升体验 error_page 404 /404.html; location /404.html { internal; } }保存后启用该站点sudo ln -sf /etc/nginx/sites-available/jenkins /etc/nginx/sites-enabled/jenkins sudo rm /etc/nginx/sites-enabled/default # 移除默认站点避免冲突 sudo nginx -t # 检查语法 sudo systemctl reload nginx # 重载配置4.4 Jenkins 端关键配置系统设置与安全加固Nginx 配置完Jenkins 端也要同步调整否则会出现403 Forbidden、crumb error、redirect loop等问题。Step 1设置 Jenkins URL系统管理 → 系统配置在 Jenkins Web UI 中进入Manage Jenkins → Configure System找到Jenkins URL字段必须填写为https://ci.yourcompany.com/结尾带斜杠。这是 Jenkins 生成所有链接如邮件通知、Webhook 回调地址、API 响应 Location 头的基准。如果填http://localhost:8080那发给 GitLab 的回调地址就是http://localhost:8080/github-webhook/GitLab 根本访问不到。Step 2配置反向代理识别Jenkins 2.307 已默认开启但需确认编辑/var/lib/jenkins/config.xml找到useSecuritytrue/useSecurity下的crumbIssuer部分确保为crumbIssuer classhudson.security.csrf.StandardCrumbIssuer excludeClientIPFromCrumbfalse/excludeClientIPFromCrumb proxyCompatibilitytrue/proxyCompatibility /crumbIssuerproxyCompatibilitytrue是关键它告诉 JenkinsX-Forwarded-*头是可信的不要用127.0.0.1做 IP 校验而要用X-Forwarded-For里的真实客户端 IP。Step 3启用 HTTPS 重定向可选双重保险在Configure Global Security页面勾选Enable security在Access Control区域Authorization选LoggedIn Users can do anything或更细粒度的 Matrix-based然后滚动到底部找到HTTP Port和HTTPS Port。由于我们用 Nginx 做 SSL 终止Jenkins 本身不需要开 HTTPS所以HTTP Port设为8080HTTPS Port留空。重点勾选Enable proxy compatibilityJenkins 2.307 该选项已整合进 crumb 配置旧版本需手动勾。做完以上重启 Jenkinssudo systemctl restart jenkins然后访问https://ci.yourcompany.com应该能正常登录创建 Job查看控制台输出且地址栏有绿色小锁。5. 常见问题与排查技巧实录5.1 典型问题速查表我把过去三年处理的 Jenkins 反代问题按发生频率排序整理成这张表。每个问题都附带现象、根因、验证命令、修复步骤照着做就能解决。问题现象根本原因快速验证命令修复步骤浏览器访问https://ci.yourcompany.com显示This site can’t be reachedNginx 未监听 443或防火墙拦截sudo ss -tlnp | grep :443sudo ufw status检查nginx.conf是否有listen 443 ssl;执行sudo ufw allow 443页面能打开但控制台日志空白F12 看 Network 里/ws/请求 400WebSocket 头未透传curl -i -N -H Connection: Upgrade -H Upgrade: websocket https://ci.yourcompany.com/ws/在location /ws/块中补全proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade;登录后点击任意链接跳转到http://localhost:8080/xxx报 404Jenkins URL 未设为https://ci.yourcompany.com/进入 Jenkins UI →Manage Jenkins → Configure System看Jenkins URL值修改为https://ci.yourcompany.com/结尾必须有斜杠保存后重启 Jenkins保存全局安全配置时报No valid crumb was included in the requestX-Forwarded-*头未透传或 Jenkins 未启用 proxyCompatibilitycurl -H X-Forwarded-For: 1.2.3.4 https://ci.yourcompany.com/crumbIssuer/api/json检查 Nginxproxy_set_header是否齐全确认/var/lib/jenkins/config.xml中proxyCompatibilitytrue/proxyCompatibility证书显示“Not Secure”Chrome 提示Your connection is not private证书链不完整缺少 intermediate certopenssl s_client -connect ci.yourcompany.com:443 -servername ci.yourcompany.com 2/dev/null | openssl x509 -noout -text | grep CA IssuersCertbot 默认生成fullchain.pem含 root intermediateNginx 配置中必须用fullchain.pem不能只用cert.pemJenkins 构建时Git 插件拉代码超时Read timeoutproxy_read_timeout太小大仓库 clone 卡住sudo tail -f /var/log/nginx/jenkins/error.log看是否有upstream timed out在location /块中增加proxy_read_timeout 600;单位秒上传大文件如.war失败报413 Request Entity Too LargeNginx 默认 client_max_body_size 为 1Mcurl -X POST -F filelarge.war https://ci.yourcompany.com/upload在server块顶部添加client_max_body_size 100M;5.2 日志分析实战三步定位问题根源Nginx 和 Jenkins 的日志是排障黄金组合。我总结了一个三步法第一步看 Nginx error.log定位网络层问题sudo tail -f /var/log/nginx/jenkins/error.log重点关注connect() failed (111: Connection refused)→ Jenkins 没启动或端口不对upstream timed out→ Jenkins 响应慢调大proxy_read_timeoutno live upstreams while connecting to upstream→upstream jenkins_backend里 server 不可达。
