当access_control为true时，Gitlab Pages OAuth重定向会挂起

Question

我正在为私有Gitlab CE安装设置Gitlab页面访问控制。我正在遵循以下管理说明：https://docs.gitlab.com/ce/administration/pages/#access-control

我已经成功设置了一个单独的DNS（example.io），用于为gitlab实例（example.com）的页面提供服务。在尝试使用gitlab配置参数access_control之前，此URL很好用。

问题

我的页面成功构建到https://group.example.io/project。我尝试访问此URL，然后按预期将我重定向到Gitlab页面OAuth页面。

当我为Gitlab Pages OAuth应用程序单击 Authorize 时，我将重定向到https://projects.example.io/auth?...，然后重定向到http://group.example.io/auth?...。请注意，最后一次重定向是通过http进行的，因为我将所有流量都配置为通过https进行引导，所以这没有任何意义。

当我查看cookie集时，我有：

• example.com-> _gitlab_session
• group.example.io-> gitlab_pages
• projects.example.io-> gitlab_pages

配置

在Ubuntu 18.08上使用gitlab omnibus。

我们的gitlab.rb配置：

pages_external_url 'https://example.io'
pages_nginx['redirect_http_to_https'] = true
pages_nginx['ssl_certificate'] = "/etc/gitlab/ssl/pages.crt"
pages_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/pages.key"
gitlab_pages['access_control'] = true

Gitlab页面的OAuth应用程序设置：

页面访问控制开关设置为仅项目成员

问题：

有人经历过这种行为吗？ 我是否已正确配置 Gitlab页面 OAuth应用程序？重定向uri应该不同吗？

编辑：

我将DNS重新配置为指向我们的LAN IP地址，系统运行正常。

我仍然感到困惑，为什么Gitlab从OAuth重定向到端口80：

网络流量似乎是：

• https://example.com/oauth/authorize?...-> 302
• https://projects.example.io/auth?..-> 302
• http://group.example.io/auth?.. -> 301永久移动
• https://group.example.io/auth?..-> 302
• http://group.example.io/project -> 301永久移动
• https://group.example.io/project-> 200

此刻我无权访问防火墙设置，但我想我们不允许80端口出站流量。这可以解释为什么当我使用公共IP地址时请求挂起，但使用LAN IP地址成功了。

但是我的问题仍然是为什么Gitlab在443上启动时会在端口80上转发流量？