「日志记录」GitLab 升级后的 HTTPS 配置之坑-Eswlnk Blog
智能摘要 AI
升级 GitLab CE 时，配置 HTTPS 访问遇到问题：GitLab 自动切换到 443 端口并尝试申请 Let’s Encrypt 证书，导致配置失败。解决方案包括关闭 Let’s Encrypt 申请、修改 `external_url` 并强制指定 Nginx 配置为监听 80 端口，最后重新配置并重启。作者建议 GitLab 应分离 `external_url` 与 Nginx 配置，默认关闭 ACME，简化运维流程。

最近在升级到新版本的 GitLab CE 并尝试配置 HTTPS 访问时，碰到了一件让我哭笑不得的事。GitLab 会自动切换到 443 端口，甚至在没有有效证书的情况下，还会尝试申请 Let’s Encrypt 的证书。这也太离谱了吧！

（PS：具体哪个版本开始这样的我也不清楚，我用的是 17.0.0。）

GitLab 的本意是，既然你修改了 external_url 包含 HTTPS，那么它就会自动化切换到 HTTPS 模式。但问题是，external_url 顾名思义只是外部 URL，GitLab 在没有配置 ACME 的情况下去申请 Let’s Encrypt 证书铁定会失败。这样一来，配置就无法通过，简直是自找麻烦。

「日志记录」GitLab 升级后的 HTTPS 配置之坑-Eswlnk Blog

作为运维，在部署 GitLab 走 HTTPS 的时候，为了证书的统一管理，通常会在外面垫一层负载均衡或者反向代理。我们需要的是 GitLab 乖乖监听 80 端口，同时在仓库的 URL 显示中展示最终代理的 URL。

要解决这个问题，需要以下几个步骤。老版本只需要改 external_url，现在搞得很麻烦。要是运维稍微不熟练，这玩意根本没法用了。

关闭 Let’s Encrypt 申请

   vi /etc/gitlab/gitlab.rb
   # 找到并修改配置
   letsencrypt['enable'] = false

修改 external_url 的同时，强行指定 GitLab 内部的 Nginx 配置

   external_url='https://xxx.com'
   nginx['listen_port'] = 80
   nginx['listen_https'] = false

重新配置并重启

   gitlab-ctl reconfigure
   gitlab-ctl restart

搞定！我必须得吐槽一下 GitLab 团队，但凡是个正常的架构设计不会这样搞。要是让我来设计，我会这样做：

  1. external_url 的配置随便写都不会影响内部 Nginx，仅用于 Web 界面上显示仓库 URL。
  2. Nginx 的配置独立化，不要集成到 gitlab.rb，单独留一个配置文件。修改后我们只需要重启 Nginx，而不是重新配置整个 GitLab。（PS：重新配置这里其实还有一个大坑，要是你用 Docker 运行会更麻烦，不展开了。）
  3. ACME 配置默认关闭，在 Web 界面的管理后台留一个配置菜单供用户编辑，输出证书即可。需要的用户再回到 GitLab 的 Nginx 改配置。

这有那么难吗？