问题复现：那个该死的 "self signed certificate" 报错

笔者作为 N8N大学 的老学长，可以负责任地告诉大家，在内网折腾 n8n 自动化时，几乎没人能绕开 SSL 证书这个坑。特别是当你试图让 n8n 去调用内网那些部署在 Docker 里、或者自建的 HTTPS 服务时。

你信心满满地搭建好了一个 Webhook 接口，或者写好了一个 HTTP Request 节点去轮询数据。点击执行，满怀期待地等待数据流转，结果日志里赫然弹出一行红色的报错：

Request failed with status code 400 或者更经典的 SSL Error: self signed certificate。

那一刻的绝望笔者深有体会。明明接口地址是对的，网络也是通的，为什么 n8n 就死活连不上？如果你正在被这个问题折磨，别急，这篇干货就是为你准备的。

原因分析：为什么 n8n 拒绝连接你的服务？

在动手解决问题之前，咱们得先用大白话搞懂底层逻辑，不然下次换个场景你又懵了。

HTTPS 协议的设计初衷是为了安全。当你访问一个正规网站（比如百度），浏览器会检查它的 SSL 证书是不是由受信任的权威机构（如 DigiCert, Let's Encrypt）签发的。这就好比警察叔叔查身份证，只有公安局发的证才认。

但在内网开发场景下，我们为了方便，通常使用 OpenSSL 或者 mkcert 自己生成一个“假身份证”——这就是自签名证书 (Self-signed Certificate)。

当 n8n（或者底层的 Node.js 环境）去请求这个地址时，它也会像浏览器一样去验证证书。发现这个证书不是权威机构签发的，它就会立刻警惕起来，认为中间人可能在搞鬼（Man-in-the-Middle Attack），于是直接拒绝请求，抛出 SSL 错误。这是 n8n 的保护机制，但在内网开发中，它反而成了拦路虎。

解决方案：3 招搞定自签名证书报错

针对这个问题，N8N大学 给大家准备了三种解法，从最简单的“无脑操作”到最规范的“一劳永逸”，大家按需取用。

方法一：全局开启“忽略 SSL 错误”开关（最快）

如果你是在 Docker 环境部署的 n8n，或者你是服务器管理员，这是最快的方法。原理是告诉 n8n 的底层环境：“别查身份证了，只要是 HTTPS 请求都给我过。”

针对 Docker 用户：

在你的 docker-compose.yml 文件中，给 n8n 的环境变量加上这一行：

N8N_SKIP_SSL_CERT_VALIDATION=true

或者在运行 Docker 命令时加上 -e N8N_SKIP_SSL_CERT_VALIDATION=true。修改后重启容器即可生效。

针对 Node.js 启动用户：

如果你是直接用 npm start 启动的，可以在启动命令前加上环境变量：

NODE_TLS_REJECT_UNAUTHORIZED=0 npm start

方法二：在 HTTP Request 节点中单独配置（最灵活）

如果你不想全局忽略 SSL（毕竟这会降低整体安全性），或者你只是想针对某一个特定的内网接口进行请求，那么就在节点内部解决。

在你的工作流中，找到 HTTP Request 节点：

1. 展开 Options（选项）部分。
2. 找到 Reject Unauthorized 这个参数。
3. 把它的值设置为 False。

这就相当于告诉这个节点：“对那个内网地址，你睁一只眼闭一只眼就行了。”这样既解决了报错，又不会影响你对外部正规接口的请求安全。

方法三：将自签名证书导入 n8n 信任列表（最正规）

这是最硬核、最规范的做法，适合那些追求极致稳定性的极客玩家。既然 n8n 不信任你的证书，那我们就想办法让 n8n 信任它。

首先，你需要导出你的自签名证书文件（通常是 .crt 或 .pem 格式）。如果你用的是 mkcert，它生成的证书通常已经兼容大部分系统。

然后，你需要找到 n8n 运行环境中的 Node.js 信任列表。这通常比较复杂，因为 n8n 的 Docker 镜像内部 Node.js 环境是独立的。

硬核操作步骤：

1. 将你的证书文件（例如 my-ca.crt）复制到 Docker 容器内部。
2. 进入容器 shell：docker exec -it n8n bash。
3. 使用 update-ca-certificates 命令（如果镜像支持）或者将证书路径添加到 NODE_EXTRA_CA_CERTS 环境变量中。

命令示例：export NODE_EXTRA_CA_CERTS=/path/to/your/my-ca.crt

虽然麻烦，但这是最彻底的解决之道，以后无论调用多少个该证书签发的接口，都不用再做任何配置。

避坑指南：这几个细节决定成败

在 N8N大学 的实战经验库中，我们发现很多同学在解决了 SSL 问题后，依然会遇到连接失败，通常是忽略了以下细节：

1. 域名解析问题（Hosts）：
很多时候，SSL 报错其实是因为证书里的 CN（通用名称）与你请求的域名不匹配。比如你的证书是签发给 192.168.1.100 的，但你在 n8n 里请求的是 https://home-server.local。即使忽略了 SSL 验证，Node.js 有时也会因为 Host 头不匹配而报错。请确保请求 URL 与证书签发域名一致。

2. 混合协议问题：
有些同学在 n8n 的配置里开启了 SSL，但反向代理（如 Nginx）配置的是 HTTP 转发。或者 n8n 自身是 HTTP，却去调用 HTTPS。这种混合协议的场景下，Ignore SSL Errors 可能会失效。请检查 n8n 的 WEBHOOK_URL 和 N8N_PROTOCOL 环境变量设置是否正确。

FAQ 问答

Q1: 开启 "Ignore SSL Errors" 会有安全风险吗？
A: 在内网环境（比如本地开发、公司内网服务调用）中，风险极低。但如果你在 n8n 中配置了公网 API 调用，建议仅针对特定的内网节点开启此选项，或者使用方法三（导入证书），不要全局关闭 SSL 验证，以防中间人攻击。

Q2: 为什么我设置了环境变量还是报错？
A: 检查你的 Docker Compose 配置缩进是否正确，或者环境变量是否被其他配置覆盖。另外，如果是 SaaS 版 n8n，你是无法修改这个设置的，只能联系管理员或改用自建版。

Q3: 自签名证书和 Let's Encrypt 证书有什么区别？
A: Let's Encrypt 是免费且受全球浏览器和系统信任的权威证书，适合公网服务。自签名证书是你自己给自己颁发的，只有你自己信任，适合内网测试或封闭系统。在 n8n 中，前者即插即用，后者需要按本文方法处理。

总结与资源

内网开发是 n8n 发挥威力的主战场，而 SSL 证书问题是必经之路。记住 N8N大学 的核心建议：

• 开发调试期：直接在 HTTP Request 节点设置 Reject Unauthorized = False，最快最省事。
• 长期运行：配置 Docker 环境变量或导入证书，一劳永逸。

希望这篇指南能帮你扫清障碍。如果你在 n8n 使用中还有其他疑难杂症，欢迎访问 N8N大学 (n8ndx.com)，这里有更多硬核的实战技巧等你来挖！