Help us learn about your current experience with the documentation. Take the survey.

排查 Geo 客户端和 HTTP 响应码错误

版本：Premium, Ultimate
产品：GitLab 自管版

修复客户端错误

LFS HTTP(S) 客户端请求的授权错误

如果您运行的是 2.4.2 版本之前的 Git LFS，可能会遇到问题。如此认证问题中所述，从从站点重定向到主站点的请求无法正确发送 Authorization 标头。这可能会导致无限的 Authorization <-> Redirect 循环，或出现授权错误消息。

在 Geo 从站点上通过 SSH 推送时出现 `Net::ReadTimeout` 错误

当您在 Geo 从站点上通过 SSH 推送大型仓库时，可能会遇到超时问题。这是因为 Rails 会将推送代理到主站点，并且默认超时时间为 60 秒，如此 Geo 问题中所述。

当前的解决方法是：

改为通过 HTTP 推送，此时 Workhorse 会将请求代理到主站点（如果未启用 Geo 代理，则会重定向到主站点）。
直接推送到主站点。

示例日志 (gitlab-shell.log)：

Failed to contact primary https://primary.domain.com/namespace/push_test.git\nError: Net::ReadTimeout\",\"result\":null}" code=500 method=POST pid=5483 url="http://127.0.0.1:3000/api/v4/geo/proxy_git_push_ssh/push"

修复 Geo 站点之间的 OAuth 授权

升级 Geo 站点时，您可能无法登录仅使用 OAuth 进行身份验证的从站点。在这种情况下，请在您的主站点上启动一个 Rails console 会话，并执行以下步骤：

要查找受影响的节点，首先列出您拥有的所有 Geo 节点：
```
GeoNode.all
```
通过指定 ID 来修复受影响的 Geo 节点：
```
GeoNode.find(<id>).repair
```

HTTP 响应码错误

启用 Geo 代理后，从站点返回 502 错误

当为从站点启用 Geo 代理功能，并且从站点用户界面返回 502 错误时，可能是从主站点代理的响应标头过大。

检查 NGINX 日志中是否有与此示例类似的错误：

2022/01/26 00:02:13 [error] 26641#0: *829148 upstream sent too big header while reading response header from upstream, client: 10.0.2.2, server: geo.staging.gitlab.com, request: "POST /users/sign_in HTTP/2.0", upstream: "http://unix:/var/opt/gitlab/gitlab-workhorse/sockets/socket:/users/sign_in", host: "geo.staging.gitlab.com", referrer: "https://geo.staging.gitlab.com/users/sign_in"

要解决此问题：

在从站点的所有 Web 节点上的 /etc/gitlab.rb 文件中设置 nginx['proxy_custom_buffer_size'] = '8k'。
使用 sudo gitlab-ctl reconfigure 重新配置从站点。

如果仍然出现此错误，您可以通过重复前面的步骤并将 8k 大小更改为 16k（例如，将其加倍）来进一步增加缓冲区大小。

Geo 管理后台显示健康状态为“未知”且“请求失败，状态码为 401”

如果使用了负载均衡器，请确保负载均衡器的 URL 已设置为负载均衡器后方节点的 /etc/gitlab/gitlab.rb 文件中的 external_url。

在主站点上，转到 管理后台 > Geo > 设置，找到 允许的 Geo IP 字段。确保从站点的 IP 地址已列出。

访问 `/admin/geo/replication/projects` 时主站点返回 500 错误

在 Geo 主站点上导航到 管理后台 > Geo > 复制（或 /admin/geo/replication/projects）会显示 500 错误，而从站点上的同一链接则可以正常工作。主站点的 production.log 中有类似以下条目：

Geo::TrackingBase::SecondaryNotConfigured: Geo secondary database is not configured
  from ee/app/models/geo/tracking_base.rb:26:in `connection'
  [..]
  from ee/app/views/admin/geo/projects/_all.html.haml:1

在 Geo 主站点上，此错误可以忽略。

发生这种情况是因为 GitLab 尝试显示来自 Geo 追踪数据库的注册信息，而该数据库在主站点上不存在（主站点上只存在原始项目；没有复制的项目，因此也不存在追踪数据库）。

当主站点的内部 URL 不正确时，可能会发生此错误。

例如，当您使用统一 URL，并且主站点的内部 URL 也等于外部 URL 时。当从站点将请求代理到主站点的内部 URL 时，这会导致循环。

要解决此问题，请将主站点的内部 URL 设置为满足以下条件的 URL：

对主站点是唯一的。
可从所有从站点访问。

访问主站点。
设置内部 URL。

从站点返回“在 CONNECT 后从代理接收到 HTTP 码 403”

如果您使用 Linux 软件包 (Omnibus) 安装了 GitLab，并且为 Gitaly 配置了 no_proxy 自定义环境变量，则可能会遇到此问题。受影响的版本：

15.4.6
15.5.0-15.5.6
15.6.0-15.6.3
15.7.0-15.7.1

这是由于 Linux 软件包 15.4.6 及更高版本中附带的 cURL 版本引入了一个错误。您应该升级到已修复此问题的更高版本。

该错误会导致 no_proxy 环境变量列表中除最后一个通配符域（.example.com）之外的所有通配符域都被忽略。因此，如果由于任何原因您无法升级到更新版本，可以通过将您的通配符域移至列表末尾来解决此问题：

编辑 /etc/gitlab/gitlab.rb：

gitaly['env'] = {
  "no_proxy" => "sever.yourdomain.org, .yourdomain.com",
}

重新配置 GitLab：
```
sudo gitlab-ctl reconfigure
```

在 no_proxy 列表中，您只能有一个通配符域。

Geo 管理后台为从站点返回 404 错误

有时，sudo gitlab-rake gitlab:geo:check 命令会显示从站点的 Rails 节点运行状况良好，但在主站点 Web 界面的 Geo 管理后台中，却返回了从站点的 404 Not Found 错误消息。