1Panel 反向代理配置 HTTPS 完整教程：从 502 报错到 Let’s Encrypt 证书申请

如果你买过 VPS，大概率早晚会遇到这么一件事：服务在服务器本机访问一切正常，可一绑定域名就报 502 Bad Gateway，申请证书又卡在验证超时。两个问题叠在一起的时候，很多人会慌，然后开始乱改配置，结果越改越乱。这篇教程就把 1Panel 反向代理加 HTTPS 的完整流程拆开讲清楚，包括 502 的根因、证书验证失败的五种常见原因，以及一套不会踩坑的操作顺序。还没入手服务器的朋友，可以先看看新手如何选购 VPS，选一台够用的机器再回来照着做。

一、先弄懂原理：请求到底是怎么走的

很多人一上来就照着教程点鼠标，遇到问题完全不知道去哪查。其实 1Panel 反向代理的链路非常简单，理解它之后，绝大多数报错都能自己判断。整个请求路径是这样的：

公网用户请求
    ↓
1Panel / OpenResty（负责 TLS 加密、域名分发）
    ↓
http://127.0.0.1:9119（你本机跑的后端服务）

1Panel 默认用 OpenResty（Nginx 的增强版）作为网关。公网用户访问 https://你的域名 时，真正处理 HTTPS 握手的是 OpenResty 这一层，而不是你的后端程序。后端服务只需要安静地监听本机某个端口，用最普通的 HTTP 协议提供服务就够了。

为什么代理地址写成 https:// 会报 502

这是 502 最常见的根源。代理地址写成 https://127.0.0.1:9119 之后，OpenResty 转发请求时会尝试和上游做一次 TLS 握手。可 9119 端口提供的是普通 HTTP，根本不会响应 TLS 握手，网关拿不到上游的合法响应，只能返回 502。反过来，如果你的后端程序本身监听了 HTTPS 端口，代理地址却写成 http://，同样会出错。所以排查时不要只盯着端口号，协议也要对得上。

遇到 502 时，按下面五条逐一确认，基本能定位九成的问题：后端进程是否在运行、端口是否在监听、监听地址是 127.0.0.1 还是 0.0.0.0、后端提供的是 HTTP 还是 HTTPS、1Panel 里的代理协议和后端是否一致。前两条用 ss -tlnp 或 netstat -tlnp 就能看，监听地址如果是 127.0.0.1，说明服务只对本机开放，公网访问不到是正常的，需要改配置或走反代。

二、准备工作

动手之前先把东西备齐，避免做到一半才发现缺条件。你需要：一台已经装好 1Panel 的云服务器；一个解析到服务器公网 IP 的域名；一个正在本机端口运行的 HTTP 服务；云厂商安全组和服务器防火墙放行 80/TCP 和 443/TCP；一个用来注册 ACME 账户的邮箱。如果域名还没买或者不知道怎么解析，先把这块搞定再继续。

本文用一套脱敏后的示例配置来讲，你自己操作时替换成真实值即可：

正式配置之前，强烈建议先在服务器上确认后端真的能返回内容。执行 curl -I http://127.0.0.1:9119，如果能看到 HTTP/1.1 200 OK，说明后端本身是通的，可以放心去配置 1Panel。如果这一步就失败，先处理容器端口映射、进程监听或服务器防火墙，不要急着申请证书，顺序错了后面全是坑。

三、六步配置流程

整体流程可以用一张表先有个概念，每一步后面有详细说明：

第一步：在 1Panel 创建网站

打开 1Panel 面板，进入 网站 → 网站，点击新建，类型选反向代理，主域名填 app.example.com。如果网站之前已经建过，直接进网站配置修改即可，不用重复添加。同时确认 DNS 服务商那边的 A 记录指向服务器公网 IP：app.example.com 解析到 203.0.113.10。DNS 刚修改时可能不会立刻生效，本地执行 nslookup app.example.com 或 dig +short app.example.com，返回的地址应该和服务器公网 IP 一致，再继续下一步。

第二步：配置反向代理并修复 502

进入 网站 → app.example.com → 配置 → 反向代理，把代理地址填写为 http://127.0.0.1:9119。如果之前填的是 https://127.0.0.1:9119 而后端只支持 HTTP，把协议改回 http:// 再保存。保存后先用 HTTP 访问 http://app.example.com 测试，页面能正常打开或者返回 200，就说明反向代理已经打通，可以进入证书环节了。

第三步：创建 ACME 账户

反向代理确认正常之后，再开始申请证书。进入 网站 → 证书 → ACME 账户，新建一个账户：CA 选择 Let’s Encrypt，邮箱填自己的常用邮箱，密钥算法选 EC 256 或 RSA 2048。个人服务用 EC 256 就够，密钥更短、握手更快；如果需要兼容非常老的客户端设备，再考虑 RSA 2048。

第四步：使用 HTTP 验证申请证书

进入 网站 → 证书 → 申请证书，主域名填 app.example.com，ACME 账户选刚创建的那个，验证方式选 HTTP 验证，自动续签开启，推送证书按需。提交之前必须确认服务器的 80/TCP 能从公网访问。如果用的是 Oracle Cloud 这类云平台，要同时检查三处：云平台的安全列表或网络安全组、服务器系统防火墙、1Panel 自带的防火墙。入站规则可以按 来源 0.0.0.0/0、协议 TCP、目标端口 80 配置。

第五步：给网站启用 HTTPS

证书签发成功后，进入 网站 → app.example.com → HTTPS 设置：HTTPS 开启，证书来源选已有证书，证书选 app.example.com 对应的那张，HTTP 选项设为重定向到 HTTPS，HTTP/2 开启。保存后访问 https://app.example.com，看到地址栏的锁标志就说明生效了。判断配置是否成功，可以看几个结果：浏览器地址栏显示 HTTPS、证书域名和当前访问域名一致、HTTP 访问自动跳转到 HTTPS、页面不再出现 502、后端服务日志能收到代理过来的请求。

也可以用命令快速验证跳转和证书：curl -I http://app.example.com 通常返回 301 或 308 并指向 HTTPS 地址；curl -I https://app.example.com 应该返回后端服务的正常状态码。两个结果都符合预期，这单就算彻底跑通了。

第六步：给第二个服务配置 HTTPS

如果还有第二个域名要上 HTTPS，比如 api.example.com，不要直接复用第一个网站的配置。推荐顺序是：先添加 api.example.com 网站，配置正确的本机反向代理地址，确认 http://api.example.com 能到达 1Panel/OpenResty，再用 HTTP 验证申请证书，签发后启用 HTTPS。如果之前用的是自签证书，签发成功后记得替换成 Let’s Encrypt 的正式证书。这里容易忽略的一点是：如果这个域名没有独立的 80 端口网站配置，HTTP 请求可能会落到 OpenResty 的默认页面，即使 DNS 正确，ACME 验证路径也无法正常工作。

四、HTTP 验证失败的排查清单

证书申请卡在验证环节是最劝退的一步，因为错误提示往往很模糊。按下面五个检查点过一遍，基本都能找到问题所在。

1. 检查 80 端口是否真正开放

云服务器开放端口通常不止改一个地方。云平台安全组放行了，系统防火墙仍然可能拦截。从另一台设备执行 curl -I http://app.example.com，如果一直超时，优先检查安全组、路由和防火墙这三层，而不是怀疑证书配置。

2. 检查域名 A 记录

确认 app.example.com 解析到 203.0.113.10。如果解析还指向旧服务器，Let’s Encrypt 会在错误的机器上查找验证文件，证书自然申请失败。这类问题排查时最容易漏掉，因为浏览器访问可能因为本地 DNS 缓存看起来”正常”。

3. Cloudflare 暂时改为仅 DNS

如果域名托管在 Cloudflare，可以在排查阶段把代理状态临时改成仅 DNS（灰色云朵）。证书签发完成、源站 HTTPS 正常之后，再根据自己的架构决定是否重新开启代理。开着橙色云朵时 Let’s Encrypt 的验证请求经过 Cloudflare 中转，多一层就多一个变量。

4. 删除错误的 AAAA 记录

如果域名存在 AAAA 记录，Let’s Encrypt 可能尝试通过 IPv6 访问验证路径。服务器没有正确配置 IPv6，而 DNS 里却留着一条 AAAA 记录，就会出现 IPv4 访问正常、证书验证却失败的情况。不用 IPv6 的话，直接删掉那条错误的 AAAA 记录，少一个坑。

5. 测试 ACME 验证路径

在浏览器或其他设备访问 http://app.example.com/.well-known/acme-challenge/test。返回 404 Not Found 不一定有问题，它至少证明请求已经到达 Web 服务器。真正需要处理的是：连接超时、域名无法解析、请求落到另一台服务器、被错误跳转或拦截、80 端口根本没有监听。

五、踩坑复盘

这些坑都是我实际踩过的，写出来帮你省点时间。

1. 对外 HTTPS，不等于上游也要写 HTTPS

一开始看到网站要启用 HTTPS，下意识把反向代理地址也写成了 https://127.0.0.1:9119。但本机服务并没有配置 TLS，OpenResty 和上游握手失败，直接 502。把上游协议改回 HTTP 后，请求马上恢复正常。这个错误特别隐蔽，因为面板、端口、域名全是对的，唯一错的就是一个字母 s。

2. 手动 DNS 验证容易卡在 TXT 记录

手动 DNS 验证不是不能用，但它依赖 TXT 记录填写正确并且及时生效。记录名、记录值、DNS 缓存、操作时间，任何一个环节出问题都可能验证超时。对于已经能开放 80 端口的普通网站，直接用 HTTP 验证就好，步骤更少，还方便自动续签，不用每次到期都手动折腾一次。

3. 顺序反了，问题会缠在一起

如果反向代理还在报 502，就急着开 HTTPS、强制跳转和 Cloudflare 代理，排查链路会越来越长，你根本分不清错误到底出在哪一层。最稳的顺序始终是：检查本机后端，配置 HTTP 反向代理，确认域名 HTTP 可访问，申请证书，开启 HTTPS，最后才开 HTTP 到 HTTPS 的跳转。

六、总结

用 1Panel 给自部署服务配置反向代理和 HTTPS，本身并不复杂，真正容易出错的是协议、端口和操作顺序。记住三个判断就够了：先用 curl 确认后端到底是 HTTP 还是 HTTPS；HTTP 验证前确保域名解析正确且公网能访问 80 端口；证书签发成功之后再开启强制 HTTPS 跳转。

这套流程不只适用于某一个服务。以后给 Docker 容器、AI 接口、个人面板或者其他自部署应用绑定域名，都可以按同样的顺序处理。比如你在 VPS 上搭建私人影音中心这类服务，只要服务跑在本机端口上，把域名和端口换成自己的，这套反向代理加证书的流程就能直接复用，具体可以看看VPS 搭建私人影音中心的完整攻略。如果服务主要面向国内用户访问，海外服务器的国内访问优化方案也值得提前读一遍，线路选对了，后续体验差距很明显。

常见问题解答（FAQ）

1. 1Panel 反向代理报 502 最常见的原因是什么？

最常见的是代理地址的协议和后端不匹配。后端只提供 HTTP，代理地址却写了 https://，OpenResty 尝试 TLS 握手失败就会返回 502。另外就是端口写错、后端进程没起来、监听地址不对。按正文里的五查清单过一遍，大部分情况五分钟内能定位。

2. 网站已经是 HTTPS，为什么反向代理地址还要写 http://？

因为 HTTPS 加密是在 1Panel/OpenResty 这一层完成的，它对外提供 HTTPS，对内转发时用自己的明文通道访问本机后端。TLS 已经终止，后端不需要再加密一次。只有后端程序自己监听了 HTTPS 端口时，代理地址才需要写成 https://。

3. Let’s Encrypt 的 HTTP 验证和 DNS 验证选哪个？

只要 80 端口能从公网访问，优先用 HTTP 验证。它步骤少、出问题容易排查，而且支持自动续签。DNS 验证适合 80 端口被占用或无法对外开放的场景，但要手动添加 TXT 记录，还要等解析生效，容易卡在验证超时。

4. 证书申请一直卡在验证中，应该先查什么？

先查 80 端口公网是否可达，再查域名 A 记录是否指向当前服务器。这两个占了验证失败的大多数。之后依次排查 Cloudflare 代理状态、多余的 AAAA 记录，最后用 .well-known/acme-challenge 路径确认请求有没有到达 Web 服务器。

5. 多个域名都要配置 HTTPS，能复用同一个证书吗？

不建议直接复用。每个域名都应该独立创建网站、独立走一遍反向代理和证书流程，排查问题时互不干扰。如果你的服务确实需要多域名共用，可以在申请证书时把多个域名加进同一张证书的 SAN 列表，但配置复杂度会高一些，新手不建议一上来就这么做。

6. 1Panel 会自动续期 Let’s Encrypt 证书吗？

会。申请证书时开启自动续签，1Panel 会在证书到期前自动处理续期。续签同样走 HTTP 验证，所以 80 端口保持开放、域名解析不变，续签就能正常完成。续签失败时面板会有提示，按正文的排查清单检查一遍即可。