GitLab自定义域名配置全攻略：从Nginx反向代理到安全防护
当企业选择自建代码托管平台时，GitLab凭借其开箱即用的CI/CD功能和丰富的权限管理体系成为首选。但直接将GitLab暴露在公网存在安全隐患，且默认的IP+端口访问方式既不专业也难以记忆。本文将手把手教你如何通过Nginx反向代理为GitLab配置专业的企业级域名访问方案，同时植入关键安全防护策略。
1. 基础环境准备
在开始配置前，确保已具备以下条件：
- 已安装GitLab Omnibus包（版本12.0+）
- 已注册域名并完成DNS解析
- 服务器已安装Nginx（版本1.18+）
- 开放80/443端口权限
验证GitLab运行状态：
sudo gitlab-ctl status正常应显示各组件"run"状态。若使用云服务器，需特别注意安全组规则是否放行8800端口（后续将用作内部通信端口）。
2. GitLab核心配置调整
首先修改GitLab主配置文件，需特别注意external_url参数将影响所有生成的仓库链接：
sudo vim /etc/gitlab/gitlab.rb关键配置项说明：
| 参数 | 示例值 | 作用 |
|---|---|---|
nginx['listen_port'] | 8800 | 内置Nginx监听端口 |
external_url | http://git.yourdomain.com | 对外访问地址 |
gitlab_rails['gitlab_shell_ssh_port'] | 22 | SSH协议端口 |
配置生效命令：
sudo gitlab-ctl reconfigure sudo gitlab-ctl restart注意：修改
external_url会导致所有项目URL变更，建议在非工作时间操作
3. Nginx反向代理配置
创建专属配置文件/etc/nginx/conf.d/gitlab.conf，以下配置包含安全增强措施：
server { listen 80; server_name git.yourdomain.com; # 静态资源缓存设置 location ~ ^/(assets|uploads)/ { expires max; add_header Cache-Control public; } location / { client_max_body_size 50m; # 安全头部增强 add_header X-Frame-Options "SAMEORIGIN"; add_header X-XSS-Protection "1; mode=block"; add_header X-Content-Type-Options "nosniff"; add_header Content-Security-Policy "default-src 'self'"; # 代理设置 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://127.0.0.1:8800; } # 爬虫拦截规则 if ($http_user_agent ~* (bot|crawler|spider|scan|python|java|curl|wget)) { return 444; } }验证并重载Nginx：
sudo nginx -t && sudo systemctl reload nginx4. HTTPS安全加固
使用Let's Encrypt免费证书实现HTTPS加密：
sudo apt install certbot python3-certbot-nginx sudo certbot --nginx -d git.yourdomain.com自动续期测试：
sudo certbot renew --dry-run配置HTTP强制跳转HTTPS：
server { listen 80; server_name git.yourdomain.com; return 301 https://$host$request_uri; }5. 高级安全防护策略
5.1 访问频率限制
在Nginx配置中添加限流规则：
limit_req_zone $binary_remote_addr zone=gitlab_limit:10m rate=30r/m; server { location / { limit_req zone=gitlab_limit burst=20 nodelay; # 原有代理配置... } }5.2 敏感操作二次验证
修改GitLab配置启用强制2FA：
# /etc/gitlab/gitlab.rb gitlab_rails['require_two_factor_authentication'] = true gitlab_rails['two_factor_grace_period'] = 48 # 小时5.3 仓库镜像防护
防止未授权仓库镜像：
# /etc/gitlab/gitlab.rb gitlab_rails['mirror_max_delay'] = 300 # 分钟 gitlab_rails['mirror_max_capacity'] = 506. 疑难问题排查
常见问题及解决方案：
| 现象 | 可能原因 | 解决方法 |
|---|---|---|
| 502错误 | Nginx与GitLab通信失败 | 检查proxy_pass端口是否匹配nginx['listen_port'] |
| 推送大文件失败 | client_max_body_size限制 | 在Nginx和GitLab中都增大该值 |
| CSS加载异常 | 混合内容问题 | 确保external_url使用HTTPS协议 |
| SSH克隆失败 | 防火墙限制 | 开放SSH端口(默认22) |
日志查看命令：
# GitLab日志 sudo gitlab-ctl tail # Nginx访问日志 tail -f /var/log/nginx/access.log7. 性能优化建议
对于高并发场景，建议调整以下参数：
# Nginx worker配置 worker_processes auto; worker_connections 4096; keepalive_timeout 65; # GitLab资源调整 unicorn['worker_timeout'] = 60 sidekiq['concurrency'] = 25 postgresql['shared_buffers'] = "256MB"内存优化方案：
sudo gitlab-ctl set-replication-password sudo gitlab-ctl puma -w 3 -t 5:5 -S /var/opt/gitlab/gitlab-rails/sockets/puma.socket经过上述配置，你的GitLab实例现在具备企业级的安全防护和性能表现。在实际运维中，建议定期检查/var/log/gitlab/nginx/current日志，及时发现异常访问行为。
