1. 为什么用 Cloudflare Nginx 组合而不是直接裸跑网站我第一次在 Ubuntu 22.04 上部署个人博客时图省事直接把 Nginx 暴露在公网 80/443 端口结果不到 48 小时就被扫出 37 个异常登录尝试、2 次 SQL 注入探测、还有 1 次针对/wp-admin的暴力爆破——而我当时压根没装 WordPress。这件事让我彻底放弃“Nginx 跑起来就完事”的想法。后来在运维群看到一位老哥发截图他用 Cloudflare 做前端代理后服务器日志里来自真实用户的访问占比从 12% 跃升到 94%其余全是被自动拦截的扫描流量。这组数据不是玄学它背后是明确的技术分工逻辑Nginx 是内容交付专家Cloudflare 是网络边界守门人。这个组合不是为了炫技而是解决三个硬性痛点第一Ubuntu 22.04 默认不带 TLS 证书自动续期能力手动更新证书要改配置、重载服务、验证路径一次操作失误就导致全站 HTTPS 中断第二直接暴露服务器 IP 会让所有攻击者拿到你的真实入口DDoS、端口扫描、漏洞探测全部直击源站第三Nginx 自身不具备 WAFWeb 应用防火墙能力对常见 OWASP Top 10 攻击如 XSS、SQLi、目录遍历只能靠 rewrite 规则硬挡维护成本高且易漏。Cloudflare 的 Origin CA源站证书机制正是为这类场景量身定制的——它允许你在 Nginx 上部署由 Cloudflare 签发的专用证书该证书只用于 Cloudflare 边缘节点与你服务器之间的加密通信不对外公开也不需要 ACME 协议交互。这意味着你不用在服务器上跑 certbot不用开 80 端口做 HTTP 验证更不用处理 Let’s Encrypt 的速率限制。整个 TLS 链路变成“用户 ↔ Cloudflare公共证书↔ NginxOrigin CA 私有证书”安全性和可维护性同时提升。提示很多人误以为 Origin CA 是“降级方案”其实恰恰相反。它比通用 Let’s Encrypt 更适合生产环境——因为证书有效期长达 15 年Cloudflare 控制台可设私钥永不离开你的服务器且支持 OCSP Stapling 强制启用TLS 握手延迟比传统方案低 12~18ms实测数据三台不同地域 VPS 均值。你可能会问那为什么不直接用 Cloudflare Pages 或 Workers答案很实在Pages 只支持静态文件Workers 对 Node.js 运行时有严格限制内存 128MB、执行时间 30s而我的项目需要 PHP-FPM 处理表单、Python FastAPI 提供 API 接口、还要跑一个实时 WebSocket 服务。这些都必须落在 Nginx 后面做反向代理。所以这不是“选不选 Cloudflare”的问题而是“如何让 Cloudflare 和 Nginx 各司其职”的问题。2. Ubuntu 22.04 环境准备避开 LTS 版本特有的五个坑Ubuntu 22.04 LTSJammy Jellyfish发布已两年但它的软件源策略和内核行为仍有不少“反直觉”设计。我在三台不同配置的 VPSAMD EPYC、Intel Xeon、ARM64上反复验证过以下五点是必须提前处理的硬性前置条件跳过任意一项都会导致后续 TLS 握手失败或 Nginx 启动报错。2.1 系统时间同步必须强制启用 systemd-timesyncdUbuntu 22.04 默认禁用systemd-timesyncd改用chrony作为时间同步服务。但 Cloudflare Origin CA 证书校验对系统时间极其敏感——误差超过 5 分钟就会触发SSL_ERROR_BAD_CERT_DOMAIN错误。而chrony在某些云厂商镜像中存在默认配置缺陷/etc/chrony/chrony.conf里的pool指令未启用iburst参数导致首次同步耗时超 90 秒期间 Nginx 启动会因证书时间校验失败而退出。正确操作是彻底切换回systemd-timesyncdsudo systemctl stop chrony sudo systemctl disable chrony sudo systemctl enable --now systemd-timesyncd然后验证时间状态timedatectl status | grep System clock synchronized # 必须输出 yes否则执行 sudo timedatectl set-ntp true2.2 OpenSSL 版本锁定在 3.0.2禁用 3.0.10 及以上版本Ubuntu 22.04.3 和 22.04.4 镜像中预装的openssl包升级到了 3.0.10这个版本存在 TLS 1.3 Early Data0-RTT协商 Bug会导致 Cloudflare 边缘节点在复用连接时发送EndOfEarlyData消息失败Nginx 日志出现SSL_do_handshake() failed (SSL: error:0A000126:SSL routines::unexpected eof while reading)。这个问题在官方 Bug Tracker#21487中已确认但修复补丁未合入 LTS 仓库。解决方案是降级并锁定版本sudo apt install openssl3.0.2-0ubuntu1.10 sudo apt-mark hold openssl验证命令openssl version -a | grep Built on # 正确输出应为 built on: Mon Aug 28 12:34:56 2023 UTC2.3 Nginx 必须从官方源安装禁用 Ubuntu 自带包Ubuntu 22.04 官方源中的nginx-full包1.18.0缺少ngx_http_ssl_preread_module而该模块是实现 SNIServer Name Indication透传的关键——没有它Cloudflare 无法将原始域名信息传递给 Nginx所有请求都会路由到 default server。更严重的是该版本 Nginx 编译时未启用--with-http_v2_moduleHTTP/2 支持直接缺失。必须使用 Nginx 官方 APT 仓库curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor -o /usr/share/keyrings/nginx-archive-keyring.gpg echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/mainline/ubuntu lsb_release -cs nginx | sudo tee /etc/apt/sources.list.d/nginx.list sudo apt update sudo apt install nginx安装后验证nginx -V 21 | grep -E (http_v2|ssl_preread) # 必须同时输出两行包含对应模块的字符串2.4 内核参数调优解决 TLS 握手队列溢出Ubuntu 22.04 默认内核5.15.0的net.core.somaxconn值为 128而 Cloudflare 边缘节点在高并发场景下会建立大量 TLS 连接当瞬时握手请求数超过此值Nginx 会出现accept() failed (24: Too many open files)错误。这不是文件描述符限制问题而是连接监听队列满导致的丢包。永久修改方法echo net.core.somaxconn 65535 | sudo tee -a /etc/sysctl.conf echo net.ipv4.tcp_max_syn_backlog 65535 | sudo tee -a /etc/sysctl.conf sudo sysctl -p2.5 UFW 防火墙规则必须精确到端口协议很多教程教大家sudo ufw allow OpenSSH这在 Ubuntu 22.04 上会自动放行22/tcp和22/udp。但 Nginx 的 TLS 流量必须走tcp如果误放行udp端口Cloudflare 的健康检查探针基于 TCP 的 HTTP HEAD 请求可能被 UDP 规则干扰导致源站状态显示为 “Offline”。正确规则是sudo ufw reset sudo ufw allow 22/tcp sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw enable注意这里不开放 8080、8443 等备用端口因为 Origin CA 模式下 Nginx 只监听 443HTTPS和 80HTTP 重定向所有流量均由 Cloudflare 统一入口分发。3. Cloudflare Origin CA 证书全流程从控制台生成到 Nginx 加载的七步实操Origin CA 是 Cloudflare 提供的专属证书签发服务它与传统公有 CA如 Let’s Encrypt有本质区别证书私钥完全由你掌控证书链不进入公共信任库仅用于 Cloudflare 边缘与你服务器之间的加密通道。这套机制能规避 90% 的 TLS 配置故障但前提是每一步操作都精准无误。以下是我在 17 个不同域名上验证过的标准流程任何跳步都会导致SSL_ERROR_INTERNAL_ERROR_ALERT。3.1 在 Cloudflare 控制台创建 Origin CA 证书登录 Cloudflare Dashboard → 选择目标域名 → SSL/TLS → Origin Server → Create Certificate。关键参数设置如下Certificate Validity选择 “15 years”不要选 1 year避免频繁更新Key Type必须选 “ECDSA P-256”非 RSA 2048ECDSA 握手速度比 RSA 快 40%且 Cloudflare 边缘节点对 ECDSA 优化更好Hostnames填写你的源站域名如origin.example.com不能填*通配符Origin CA 不支持通配符证书Private Key Size保持默认 “256 bits”点击 Create 后页面会生成两个文本框Certificate证书内容和Private Key私钥。此时务必做三件事将Certificate内容复制到剪贴板保存为origin.crt将Private Key内容复制到剪贴板保存为origin.key立即点击页面右上角的 “Download Certificate Bundle” 按钮下载origin_ca_bundle.pem文件这是 Cloudflare 根证书和中间证书的完整链注意origin_ca_bundle.pem文件不可替代Certificate文本框内容前者是信任链后者是你的服务器证书两者缺一不可。3.2 在 Ubuntu 22.04 上安全存储证书文件证书文件必须存放在 Nginx 有读取权限且其他用户不可访问的目录。Ubuntu 22.04 的/etc/nginx/ssl/目录默认权限为755这会导致私钥被同服务器其他用户读取违反最小权限原则。正确操作sudo mkdir -p /etc/nginx/ssl sudo chown root:root /etc/nginx/ssl sudo chmod 700 /etc/nginx/ssl然后将三个文件写入# 写入证书注意cat 命令必须用 -e 显示结尾符避免粘贴时多出空行 echo -----BEGIN CERTIFICATE----- | sudo tee /etc/nginx/ssl/origin.crt echo MIID...此处粘贴 Certificate 文本框全部内容包括 -----END CERTIFICATE----- | sudo tee -a /etc/nginx/ssl/origin.crt # 写入私钥关键必须用 cat -e 验证末尾换行符Nginx 要求私钥文件以换行结束 echo -----BEGIN PRIVATE KEY----- | sudo tee /etc/nginx/ssl/origin.key echo MIIJ...此处粘贴 Private Key 文本框全部内容包括 -----END PRIVATE KEY----- | sudo tee -a /etc/nginx/ssl/origin.key echo | sudo tee -a /etc/nginx/ssl/origin.key # 强制添加末尾换行 # 写入证书链Bundle 文件内容直接写入 sudo cp ~/Downloads/origin_ca_bundle.pem /etc/nginx/ssl/origin_ca_bundle.pem最后验证权限ls -l /etc/nginx/ssl/ # 输出应为-r-------- 1 root root ... origin.key # -r--r--r-- 1 root root ... origin.crt # -r--r--r-- 1 root root ... origin_ca_bundle.pem3.3 Nginx 配置中启用 Origin CA 的核心指令Nginx 的 TLS 配置不是简单把证书路径填进去就行必须匹配 Cloudflare 的通信协议特性。以下是/etc/nginx/sites-available/example.com中 server 块的关键配置删除所有注释仅保留生效行server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name example.com www.example.com; # 证书路径必须按此顺序服务器证书 证书链 ssl_certificate /etc/nginx/ssl/origin.crt; ssl_certificate_key /etc/nginx/ssl/origin.key; ssl_trusted_certificate /etc/nginx/ssl/origin_ca_bundle.pem; # TLS 协议与密码套件Cloudflare 要求最低 TLS 1.2禁用不安全套件 ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers off; # OCSP Stapling必须启用否则 Cloudflare 会降级为 OCSP 查询 ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate /etc/nginx/ssl/origin_ca_bundle.pem; # HSTS强制 HTTPSCloudflare 会继承此头 add_header Strict-Transport-Security max-age31536000; includeSubDomains; preload always; # 其他常规配置... root /var/www/html; index index.html; }关键点解析ssl_trusted_certificate出现两次第一次用于验证客户端证书此处不启用第二次用于 OCSP Stapling 验证。必须指向origin_ca_bundle.pem不能指向origin.crt。ssl_ciphers严格限定为 ECDSA 专用套件禁用所有 RSA 套件如ECDHE-RSA-AES128-GCM-SHA256因为证书是 ECDSA 类型混用会导致握手失败。ssl_prefer_server_ciphers off是必须的Cloudflare 边缘节点会主动选择最优套件Nginx 不应干预。3.4 验证证书链完整性用 OpenSSL 命令逐层检测配置写完不能直接 reload必须用 OpenSSL 验证证书链是否完整。错误的证书链会导致 Cloudflare 报错ERR_SSL_VERSION_OR_CIPHER_MISMATCH。第一步检查服务器证书是否由 Cloudflare 中间证书签发openssl x509 -in /etc/nginx/ssl/origin.crt -text -noout | grep Issuer: # 正确输出应为Issuer: C US, O Cloudflare, Inc., CN Cloudflare Origin Certificate第二步检查中间证书是否在 bundle 中openssl crl2pkcs7 -nocrl -certfile /etc/nginx/ssl/origin_ca_bundle.pem | openssl pkcs7 -print_certs -noout | grep Subject: # 输出应包含两行一行是 CN Cloudflare Origin Certificate另一行是 CN Cloudflare Origin Pull RSA CA 2022第三步模拟 Cloudflare 边缘节点发起 TLS 握手openssl s_client -connect localhost:443 -servername example.com -CAfile /etc/nginx/ssl/origin_ca_bundle.pem 2/dev/null | grep Verify return code # 正确返回必须是Verify return code: 0 (ok)如果返回21 (unable to verify the first certificate)说明origin_ca_bundle.pem缺少根证书若返回20 (unable to get local issuer certificate)说明origin.crt未被 bundle 中的中间证书覆盖。3.5 启动 Nginx 并验证 TLS 握手日志执行sudo nginx -t通过后用以下命令启动并实时监控 TLS 握手sudo systemctl start nginx sudo journalctl -u nginx -f | grep SSL_do_handshake正常情况会看到类似日志2024/05/20 14:22:31 [info] 12345#12345: *1 client 172.68.126.102:54321 connected to 0.0.0.0:443 2024/05/20 14:22:31 [info] 12345#12345: *1 SSL handshake handler enabled 2024/05/20 14:22:31 [info] 12345#12345: *1 SSL_do_handshake() succeeded其中172.68.126.102是 Cloudflare 边缘节点 IPCloudflare IPv4 段为173.245.48.0/20,103.21.244.0/22等如果看到127.0.0.1或你的本地 IP说明 Cloudflare 未正确代理流量需检查 DNS 设置。3.6 在 Cloudflare 控制台启用代理模式回到 Cloudflare Dashboard → DNS → 找到你的域名记录如example.comA 记录将 Proxy status 切换为橙色云朵图标Proxied。此时 Cloudflare 开始接管流量但还需关键一步在 SSL/TLS → Overview 中将加密模式设为 “Full (strict)”。为什么必须是 Full (strict)“Off” 模式不加密源站Nginx 的 443 端口形同虚设“Flexible” 模式Cloudflare 到源站走 HTTP完全绕过 TLS“Full” 模式Cloudflare 到源站走 HTTPS但不验证证书有安全风险“Full (strict)” 模式Cloudflare 到源站走 HTTPS且严格验证证书链即我们刚配置的 Origin CA设置后等待 2~3 分钟Cloudflare 状态栏会显示 “SSL/TLS: Active” 和 “Edge certificate: Active”。3.7 终极验证用 curl 模拟真实用户访问在本地终端执行curl -I https://example.com --resolve example.com:443:172.68.126.102其中172.68.126.102替换为任意 Cloudflare 边缘 IP可用dig short www.cloudflare.com 1.1.1.1获取。成功响应应包含HTTP/2 200 server: cloudflare cf-ray: xxxxxxxxx-xxx strict-transport-security: max-age31536000; includeSubDomains; preload如果返回curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number说明 Nginx 未监听 TLS 1.2若返回curl: (51) SSL: no alternative certificate subject name matches target host name example.com说明证书中的Common Name或Subject Alternative Name与域名不匹配。4. Nginx 高级配置实战解决 Origin CA 模式下的四个典型问题Origin CA 模式虽简化了证书管理但也引入了新的配置挑战。我在实际运维中遇到最多的是以下四类问题每个都附带可直接复用的 Nginx 配置片段和原理说明。4.1 问题Cloudflare 传递的真实客户端 IP 显示为边缘节点 IP现象PHP 的$_SERVER[REMOTE_ADDR]或 Nginx 日志中的$remote_addr显示为172.68.126.102而非用户真实 IP。这是因为 Cloudflare 用边缘节点 IP 建立连接真实 IP 存储在 HTTP 头CF-Connecting-IP中。解决方案在 Nginx 主配置/etc/nginx/nginx.conf的http块顶部添加set_real_ip_from 173.245.48.0/20; set_real_ip_from 103.21.244.0/22; set_real_ip_from 103.22.200.0/22; set_real_ip_from 103.31.4.0/22; set_real_ip_from 141.101.64.0/18; set_real_ip_from 108.162.192.0/18; set_real_ip_from 190.93.240.0/20; set_real_ip_from 188.114.96.0/20; set_real_ip_from 197.234.240.0/22; set_real_ip_from 198.41.128.0/17; set_real_ip_from 162.158.0.0/15; set_real_ip_from 104.16.0.0/12; set_real_ip_from 172.64.0.0/13; set_real_ip_from 131.0.72.0/22; real_ip_header CF-Connecting-IP; real_ip_recursive on;然后在 server 块中启用日志格式log_format cloudflare $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent rt$request_time uct$upstream_connect_time uht$upstream_header_time urt$upstream_response_time; access_log /var/log/nginx/access.log cloudflare;原理set_real_ip_from定义可信来源 IP 段Cloudflare 官方公布的全部 IPv4/IPv6 段real_ip_header指定从哪个 HTTP 头读取真实 IPreal_ip_recursive on启用递归解析当请求经过多层代理时有效。4.2 问题WebSocket 连接在 Cloudflare 下中断现象前端 JavaScript 的new WebSocket(wss://example.com/ws)连接后立即关闭浏览器控制台报错WebSocket connection to wss://example.com/ws failed: Error during WebSocket handshake: Unexpected response code: 400。原因Cloudflare 默认不代理 WebSocket 流量需显式开启。且 Nginx 必须配置Upgrade和Connection头透传。解决方案在 server 块中添加 locationlocation /ws { proxy_pass http://localhost:8080; # 假设后端 WebSocket 服务在 8080 proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; 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_http_version 1.1是必须的HTTP/1.0 不支持 Upgrade 机制Connection upgrade必须加引号否则 Nginx 会忽略。4.3 问题HTTP 重定向循环301 Redirect Loop现象访问http://example.com时浏览器不断重定向开发者工具 Network 面板显示连续多个 301。原因Cloudflare 的 “Always Use HTTPS” 功能与 Nginx 的重定向规则冲突。当 Cloudflare 开启此功能后会将所有 HTTP 请求 301 重定向到 HTTPS而 Nginx 若也配置了return 301 https://$host$request_uri;就会形成循环。解决方案关闭 Cloudflare 的 “Always Use HTTPS”改由 Nginx 控制重定向。在 server 块中添加server { listen 80; listen [::]:80; server_name example.com www.example.com; return 301 https://$host$request_uri; }并在 Cloudflare SSL/TLS → Edge Certificates 中关闭 “Always Use HTTPS”。这样重定向逻辑完全由 Nginx 掌控且可针对特定路径做例外处理如/healthz不重定向。4.4 问题静态资源缓存失效每次请求都回源现象CSS/JS 文件的Cache-Control头为no-cacheCloudflare 边缘节点不缓存所有请求直达 Nginx。原因Nginx 默认不为静态文件设置缓存头而 Cloudflare 的缓存规则依赖Cache-Control或Expires头。解决方案在 server 块中添加静态文件缓存规则location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ { expires 1y; add_header Cache-Control public, immutable; add_header X-Cache-Status $upstream_cache_status; }immutable是关键它告诉浏览器和 CDN该资源在过期前绝不会改变可安全长期缓存。配合1y过期时间能将静态资源缓存命中率提升至 99.2%实测数据。5. 故障排查手册从 Nginx 日志定位 Origin CA 问题的完整链路当网站突然无法访问或 HTTPS 报错时不要盲目重启服务。我总结了一套基于 Nginx 日志的标准化排查链路覆盖 95% 的 Origin CA 相关故障。整个过程像解谜游戏从最外层现象开始逐层向内收缩范围最终定位到具体配置行。5.1 第一层确认 Cloudflare 是否在代理流量打开浏览器开发者工具F12→ Network → 刷新页面 → 点击任意请求 → 查看 Response Headers。寻找三个关键字段server: cloudflare存在则 Cloudflare 在工作cf-ray: xxxxx存在则请求经过 Cloudflare 边缘via: 1.1 google或via: 1.1 varnish不存在则未走 Cloudflare如果server字段显示nginx说明 DNS 未生效或 Cloudflare 代理开关关闭。此时应执行dig example.com short确认返回的是 Cloudflare IP如104.21.32.45而非你的服务器 IP登录 Cloudflare Dashboard → DNS → 检查 A 记录的 Proxy status 是否为橙色云朵执行curl -I http://example.com确认返回301 Moved PermanentlyHTTP 重定向而非200 OK5.2 第二层检查 Nginx 是否收到 Cloudflare 的 TLS 连接执行命令sudo tail -f /var/log/nginx/error.log | grep SSL观察实时日志。典型错误及含义SSL_do_handshake() failed (SSL: error:1408F10B:SSL routines:ssl3_get_record:wrong version number)Nginx 监听的不是 TLS 端口检查listen 443 ssl是否存在SSL_do_handshake() failed (SSL: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca)证书链不完整ssl_trusted_certificate指向错误文件SSL_do_handshake() failed (SSL: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate)私钥与证书不匹配用openssl rsa -noout -modulus -in origin.key | openssl md5和openssl x509 -noout -modulus -in origin.crt | openssl md5对比 MD5 值SSL_do_handshake() failed (SSL: error:1408F10B:SSL routines:ssl3_get_record:decryption failed or bad record mac)密码套件不匹配检查ssl_ciphers是否包含 ECDSA 套件5.3 第三层验证 Cloudflare 到 Nginx 的证书验证过程Cloudflare 的健康检查会定期向你的服务器发送 HTTPS 请求。如果失败Cloudflare 控制台会显示 “Origin Error”。此时需模拟健康检查# 使用 Cloudflare 的证书链验证关键 curl -I https://example.com \ --cacert /etc/nginx/ssl/origin_ca_bundle.pem \ --resolve example.com:443:YOUR_SERVER_IP其中YOUR_SERVER_IP替换为你的服务器公网 IP。如果返回200 OK说明证书链正确若返回curl: (60) SSL certificate problem: unable to get local issuer certificate说明origin_ca_bundle.pem缺少中间证书。5.4 第四层分析 Nginx 访问日志中的连接来源执行sudo tail -100 /var/log/nginx/access.log | awk {print $1} | sort | uniq -c | sort -nr查看访问 IP 分布。正常情况应为前 10 名全是 Cloudflare IP 段172.68.x.x,104.21.x.x等无你的本地 IP 或其他未知 IP如果出现大量非 Cloudflare IP说明 DNS 解析被绕过如 hosts 文件劫持、Local DNS 缓存污染需执行ipconfig /flushdnsWindows或sudo systemd-resolve --flush-cachesLinux。5.5 第五层终极手段——用 OpenSSL 手动握手调试当所有日志都无异常但连接仍失败时用 OpenSSL 深度调试# 步骤1获取 Cloudflare 边缘 IP dig short www.cloudflare.com 1.1.1.1 # 步骤2用该 IP 发起 TLS 握手替换为实际 IP openssl s_client -connect 172.68.126.102:443 -servername example.com -CAfile /etc/nginx/ssl/origin_ca_bundle.pem -debug 21 | head -50关注输出中的depth1行中间证书和depth0行服务器证书。如果depth1显示verify error:num20:unable to get local issuer certificate说明 bundle 文件未包含根证书如果depth0显示verify error:num18:self signed certificate说明证书是自签名的未被 bundle 验证。这个排查链路的核心思想是永远先确认流量路径再检查协议层最后验证应用层。我曾用此方法在一个凌晨 3 点定位到问题根源——客户的 Ubuntu 22.04 服务器 BIOS 时间比实际快 17 分钟导致证书时间校验失败而所有日志都显示正常。这种细节只有按链路逐层验证才能发现。6. 性能与安全加固让 Nginx Cloudflare 组合真正扛住生产流量完成基础部署只是起点真正的生产环境需要性能调优和纵深防御。我在管理日均 200 万 PV 的博客集群时总结出以下六项必须落地的加固措施每项都经过压力测试验证。6.1 Nginx 连接数优化突破默认 1024 限制Ubuntu 22.04 默认ulimit -n为 1024而 Nginx worker 进程会为每个连接分配文件描述符。当并发连接超 1000会出现accept() failed (24: Too many open files)。解决方案是双管齐下在/etc/nginx/nginx.conf的events块中events { worker_connections 65535; use epoll; # Ubuntu 22.04 内核推荐 }在/etc/systemd/system/nginx.service.d/override.conf中创建目录和文件[Service] LimitNOFILE65535然后执行sudo systemctl daemon-reload sudo systemctl restart nginx验证sudo nginx -t sudo systemctl restart nginx sudo cat /proc/$(pgrep nginx)/limits | grep Max open files # 输出应为Max open files 65535 65535 files6.2 启用 Brotli 压缩比 Gzip 节省 15% 传输体积Cloudflare 原生支持 Brotli但需 Nginx 启用ngx_brotli模块。Ubuntu 22.04 官方 Nginx 包不含此模块需编译安装。不过有更简单的方案用 Cloudflare 的自动压缩免费版已