一次 SSL 证书问题排查小结

Sun, 19 Apr 2026 00:00:00 +0000

今天解决了一个 nanobot gateway 启动失败的问题，记录一下排查过程和学到的东西。

问题现象

启动 nanobot gateway 时报错：

ssl.SSLCertVerificationError: certificate verify failed: self-signed certificate in certificate chain

排查过程

第一反应：代理问题？

因为错误是 “self-signed certificate”，第一反应是 Clash Party 的 HTTPS 拦截又在搞事情。之前确实碰到过类似问题。

于是：

重启 Clash Party
排除飞书相关域名
完全退出飞书应用

然并卵。

柳暗花明

最后用 ssl.get_default_verify_paths() 检查 Python 的 SSL 配置：

>>> import ssl
>>> ssl.get_default_verify_paths()
DefaultVerifyPaths(cafile=None, capath=None, 
    openssl_cafile='/Library/Frameworks/Python.framework/Versions/3.12/etc/openssl/cert.pem',
    openssl_cafile_env='SSL_CERT_FILE', ...)

问题找到了：Python 期望证书在 /Library/Frameworks/Python.framework/Versions/3.12/etc/openssl/cert.pem，但这个文件不存在！

macOS 系统的证书实际在 /etc/ssl/cert.pem（由 Apple 维护，6000+ 根证书）。

解决

设置环境变量：

export SSL_CERT_FILE=/etc/ssl/cert.pem

添加到 ~/.zshrc 永久生效。

学到的教训

不要先入为主：“self-signed certificate” 不一定是中间人攻击，也可能是证书路径没配好
Python SSL 排查：第一时间检查 ssl.get_default_verify_paths() 能快速定位
macOS Python 的坑：系统自带的 Python（官方安装包）没有正确配置系统证书路径，Homebrew 版会好一些

问题虽然简单，但排查方向跑偏了半小时。下次遇到 SSL 错误会先检查证书路径配置。

Cloudflare 捉迷藏：我是如何被产品经理玩弄了三小时的

Sat, 19 Apr 2025 00:00:00 +0000

Cloudflare 捉迷藏：我是如何被产品经理玩弄了三小时的

建一个极简的静态博客需要多久？

看完网上的教程，我以为最多只要十分钟。毕竟“Hugo + GitHub + Cloudflare Pages”已经是目前公认最省心、最长久的“养老级”建站配方。我连博客的定位都想好了——一个没有任何社交元素、只有纯粹文字的“安静后花园”。

但现实给我狠狠上了一课：在这个代码甚至都能让 AI 帮着写的时代，打败你的，往往只是一个被产品经理藏起来的按钮。

掉进“伪装者”的陷阱

一切的起步都很顺利。本地安装 Hugo，挑了一个极简的 PaperMod 主题，写好 Markdown 测试页，推送到 GitHub。这部分如丝般顺滑，让我产生了一种“我也是极客”的错觉。

直到我打开 Cloudflare 准备部署上线。

按照教程，我应该找到一个叫“Pages”的入口，连上 Git，然后一键发布。但我眼前的界面只有“Create Application”。我毫不犹豫地点了进去，选了 GitHub 仓库，然后噩梦就开始了。

构建报错：Command failed with exit code 1: npx hugo。系统提示找不到 hugo 的 npm 包，日志里还混杂着 npx wrangler deploy 这种我根本看不懂的指令。

我翻遍了所有的报错帖，有人说要改环境变量，有人说要查子模块。我改了无数次 hugo.toml 里的 baseURL，在终端里敲烂了 git push，但迎来的始终是一片苍白的空白页。

更绝望的是，教程里说要在“Edit output settings”里把输出目录填成 public，而我的后台设置里，连这个选项的影子都没有，只有一个孤零零的“Root directory”。

我开始严重怀疑自己：这么简单的事情，大家都说点几个按钮就好，为什么我不行？难道我连做个数字废物的资格都没有了吗？

产品经理的“阴谋”

在与 AI 助手进行了长达一小时的极限拉扯，逐行分析了构建日志后，真相终于浮出水面。

根本不是我的代码有问题，而是我进错了门。

Cloudflare 最近为了推行他们宏大的“全家桶”战略，把用来运行复杂代码的 Workers 和用来托管静态页面的 Pages 强行塞进了一个入口。当你兴冲冲地点开“Create Application”时，系统默认把你引导到了更为复杂的 Workers（代码部署）模式。

在这个模式下，它不认识什么 Hugo 预设，也不自动找 public 文件夹，它只会按照处理代码的逻辑一顿瞎跑，最后给你扔一堆报错。

而真正适合普通人、带有一键自动化流水线的 Pages 模式，被折叠、隐藏在了一个需要切换选项卡才能看到的偏僻角落。

如果你不仔细看，根本发现不了那个极其微小的“Connect to Git”按钮。连国外技术社区的大佬都在截图吐槽：“Ah! Sneaky! I did not see that. Is Cloudflare trying to phase out Pages?"（太狡猾了！我根本没看到。Cloudflare 是想把 Pages 淘汰掉吗？）

原来，全世界的极客都在被这套“自作聪明”的 UI 设计折磨。

破局与开园

解决问题的方法简单得令人发指，也更加印证了之前的折腾有多荒谬：

把那个错误的、折磨了我几个小时的 Worker 项目直接删除。
回到起点，点击 Create。强迫自己无视下方巨大的诱导按钮，点击上方那个不起眼的【Pages】选项卡。
终于，那个熟悉的“Connect to Git”出现了。

选好仓库，在 Framework preset 里选上 Hugo。就在那一瞬间，失踪的 Build command 和 Output directory 像变魔术一样自动弹了出来。

点击“Save and Deploy”。几十秒后，页面上亮起了绿色的 “Success: Your site is deployed”。

点开链接，大白底、黑字的极简博客瞬间加载出来，排版完美，没有任何报错。

看着这个干净的页面，我长长地舒了一口气。三个小时的自我怀疑和愤怒，在这一刻烟消云散。

虽然过程曲折得像是在玩一场极其恶劣的捉迷藏，但好在，我终于拿到了自家后花园的钥匙。这篇碎碎念就作为开园的第一篇文章吧，留给未来的自己，也留给下一个在 Cloudflare 迷路的倒霉蛋：

兄弟，不要怀疑你的代码，去怀疑产品经理。

无论多晚都陪着我

Sat, 19 Apr 2025 00:00:00 +0000

无论多晚都陪着我❤️

报道先生归也

Fri, 18 Apr 2025 00:00:00 +0000

报道先生归也，杏花春雨江南。

看到喜欢的诗句，心里总是忍不住喜悦和感动！

First Shot

Tue, 15 Apr 2025 00:00:00 +0000

first shot

hugo yyds
obsidian yyds

思考

Tue, 15 Apr 2025 00:00:00 +0000

Posts on awka

一次 SSL 证书问题排查小结

问题现象

排查过程

第一反应：代理问题？

柳暗花明

解决

学到的教训

Cloudflare 捉迷藏：我是如何被产品经理玩弄了三小时的

Cloudflare 捉迷藏：我是如何被产品经理玩弄了三小时的

掉进“伪装者”的陷阱

产品经理的“阴谋”

破局与开园

无论多晚都陪着我

报道先生归也

First Shot

first shot

思考

一个人达到成就的多少，主要看你是否是一个强目标驱动的人。