引言：网页加载变慢的“元凶”
在使用 GitLab 的过程中，很多团队可能会遇到这样一个问题：某天突然发现 GitLab 的网页打开异常缓慢，页面上的用户头像全部变成了裂开的图标。
按下 F12 打开浏览器的开发者工具，你大概率会在 Network（网络）面板中发现，大量针对第三方头像源（例如 sdn.geekzu.org）的请求处于 Pending 或 Timeout 状态。
由于网络环境的变化，一些曾经好用的国内 Gravatar 镜像源可能会失效或变得极其不稳定。由于前端加载被这些外部图片请求阻塞，整个 GitLab 的使用体验就会大打折扣。今天，我们就以 Docker 部署的 GitLab 为例，手把手教你如何快速停用或更换这些失效的头像源。
一、 确认我们的部署环境
在这篇教程中，我们假设你的 GitLab 是通过 Docker 进行部署的。这也是目前最主流、最便于维护的部署方式。
假设你当初启动 GitLab 容器的命令如下（这也是非常标准的企业级部署命令）：
sudo docker run -d \
-p 443:443 -p 8088:8088 -p 222:22 \
--name gitlab \
--restart always \
-v /mnt/gitlabdata/config:/etc/gitlab \
-v /mnt/gitlabdata/logs:/var/log/gitlab \
-v /mnt/gitlabdata/data:/var/opt/gitlab \
gitlab/gitlab-ee:18.10.8-ee.0
关键点解析：
从上面的 -v 参数可以看出，我们将容器内的 /etc/gitlab 目录映射到了宿主机的 /mnt/gitlabdata/config。这意味着，我们不需要进入容器内部，直接在宿主机修改配置文件即可。
二、 定位并修改配置文件
GitLab 的核心配置文件是 gitlab.rb。在我们的环境中，它位于宿主机的 /mnt/gitlabdata/config/gitlab.rb。
使用文本编辑器打开它：
sudo vim /mnt/gitlabdata/config/gitlab.rb
通过搜索功能（在 vim 中输入 /gravatar），你可能会找到类似下面这样的自定义配置，这就是导致头像加载失败的源头：
# 之前配置的失效镜像源
gitlab_rails['gravatar_plain_url'] = 'https://sdn.geekzu.org/avatar/%{hash}?s=%{size}&d=identicon'
gitlab_rails['gravatar_ssl_url'] = 'https://sdn.geekzu.org/avatar/%{hash}?s=%{size}&d=identicon'
面对这个问题，我们有两种解决思路，你可以根据团队的实际需求进行选择：
方案 A：彻底关闭外部头像源（强烈推荐）
对于大多数企业内部署的私有化 GitLab 来说，花里胡哨的头像并不是刚需。关闭外部请求不仅能彻底杜绝头像源失效导致卡顿的问题，还能大幅提升页面的加载速度。关闭后，GitLab 会自动使用用户名字的首字母作为默认头像，简洁且美观。
修改方法：将原有的源注释掉，并显式将 gravatar_enabled 设置为 false。
# 1. 注释掉失效的自定义源
# gitlab_rails['gravatar_plain_url'] = 'https://sdn.geekzu.org/avatar/%{hash}?s=%{size}&d=identicon'
# gitlab_rails['gravatar_ssl_url'] = 'https://sdn.geekzu.org/avatar/%{hash}?s=%{size}&d=identicon'
# 2. 增加这一行，彻底关闭 Gravatar 支持
gitlab_rails['gravatar_enabled'] = false
方案 B：恢复为 GitLab 官方默认源
如果你仍然希望保留全局头像功能，只是想抛弃 geekzu 这个不稳定的源，你可以直接恢复官方默认设置。GitLab 默认内置了安全的官方 Gravatar 地址。
修改方法：仅仅注释掉自定义源，并确保功能处于开启状态。
# 1. 注释掉自定义的 geekzu 源
# gitlab_rails['gravatar_plain_url'] = 'https://sdn.geekzu.org/avatar/%{hash}?s=%{size}&d=identicon'
# gitlab_rails['gravatar_ssl_url'] = 'https://sdn.geekzu.org/avatar/%{hash}?s=%{size}&d=identicon'
# 2. 确保启用 Gravatar（如果不填，系统默认也会是 true）
gitlab_rails['gravatar_enabled'] = true
三、 无缝重载：让配置优雅生效
很多新手在修改完 Docker 容器的相关配置后，第一反应是直接 docker restart gitlab。虽然这样也能生效，但 GitLab 容器极为庞大，完整的重启过程可能需要几分钟，期间整个代码库将处于不可用状态。
更优雅的做法是：直接在运行中的容器内执行重载命令。
保存退出 gitlab.rb 文件后，在宿主机终端执行以下命令：
sudo docker exec -it gitlab gitlab-ctl reconfigure
原理解析：
docker exec -it gitlab：告诉 Docker 在名为gitlab的容器内部执行命令。gitlab-ctl reconfigure：这是 GitLab 自带的管理工具，它会重新读取gitlab.rb配置文件，并动态应用更新，无需重启核心服务。
等待屏幕上跑完一串绿色的日志，显示 gitlab Reconfigured! 时，配置就已经生效了。
这时候，回到浏览器中强制刷新一下 GitLab 页面（Ctrl + F5），你会发现那个拖慢速度的头像请求彻底消失了，页面加载速度瞬间起飞！
四、 总结与最佳实践建议
通过这次调整，我们不仅解决了 GitLab 的性能痛点，也重温了 Docker 部署下的标准运维流程。这里总结两点最佳实践：
- 坚持数据持久化挂载：就像我们在启动命令中看到的那样，将
config、logs和data目录挂载到宿主机是非常关键的。这使得我们修改配置极其方便，并且未来在升级 GitLab 版本时，只需销毁旧容器拉取新镜像，数据依然完好无损。 - 私有化环境尽量减少外部依赖：对于内网或对稳定性要求极高的系统服务，尽量减少对外部第三方 API（如外部字体、外部头像库等）的依赖，这往往是提升系统健壮性最简单有效的方法。
希望这篇文章能帮到正在被 GitLab 头像加载问题困扰的你！如果有其他关于 GitLab 或 Docker 运维的问题，欢迎在评论区讨论。
版权属于：soarli
本文链接：https://blog.soarli.top/archives/1102.html
转载时须注明出处及本声明。
