GitLab容器启动后80端口无法访问，主因是资源不足（需≥4GB RAM、2核CPU）导致内部服务未启动；须通过GITLAB_OMNIBUS_CONFIG关闭冗余服务、挂载三个必需卷、执行gitlab-ctl reconfigure与status检查；external_url不生效需配置real_ip_trusted_addresses和real_ip_header；Runner注册失败需设nginx.listen_addresses=["0.0.0.0"]；升级报500错须用gitlab-ctl upgrade完成数据库迁移并修正卷权限为git:root。
GitLab 容器启动后打不开 80 端口
默认用 docker run -d -p 80:80 启动 GitLab，浏览器访问 http://localhost 却显示连接被拒绝或 Nginx 502 —— 这不是端口没映射，而是 GitLab 内部服务（主要是 unicorn 和 sidekiq）根本没起来，常见于内存不足或配置未适配。
GitLab CE 官方镜像对资源有硬性要求：至少 4GB RAM、2 核 CPU；低于此规格时，容器会静默卡在初始化阶段，docker logs -f <container_id> 里反复出现 Waiting for database... 或 PG::ConnectionBad，但不会报错退出。
- 必须用
-e GITLAB_OMNIBUS_CONFIG显式关闭非必要服务：比如加postgresql['enable'] = false（如果你用外部 PG），否则内置 PostgreSQL 会抢光内存 - 务必挂载
/etc/gitlab、/var/log/gitlab、/var/opt/gitlab三个卷，缺一不可；/var/opt/gitlab未持久化会导致每次重启都重装数据库 - 首次启动后别急着访问，执行
docker exec -it <container_id> gitlab-ctl reconfigure确认配置写入，再gitlab-ctl status检查nginx、redis、postgresql是否全为run
GitLab 配置 external_url 后仓库克隆地址不对
改了 external_url "https://gitlab.example.com"，Web 页面显示的 clone 地址却是 http://localhost:8080/xxx.git —— 这是 GitLab 没识别到反向代理的真实请求头，它按容器内网地址自动生成 URL。
根本原因在于：GitLab 默认信任 127.0.0.1 和 ::1 的 X-Forwarded-* 头，而 Docker 桥接网络中宿主机 IP（如 172.17.0.1）不在白名单里，导致 nginx['real_ip_trusted_addresses'] 不生效。
- 在
GITLAB_OMNIBUS_CONFIG中追加：nginx['real_ip_trusted_addresses'] = ["127.0.0.1", "172.17.0.0/16", "192.168.0.0/16"]（按你实际 docker0 网段调整） - 同时必须启用：
nginx['real_ip_header'] = "X-Forwarded-For"，否则即使地址可信，也不会解析真实客户端 IP - 如果走 Nginx 反代，确保反代配置里有
proxy_set_header Host $host;和proxy_set_header X-Forwarded-Ssl on;（HTTPS 场景下缺这个会导致 GitLab 生成 http:// 地址）
GitLab Runner 注册失败：dial tcp 127.0.0.1:443: connect: connection refused
在宿主机执行 gitlab-runner register，填完 URL 和 token 后报这个错 —— 表示 Runner 尝试直连容器内的 GitLab，但容器默认只监听 127.0.0.1:80（即仅限容器内部访问），外部根本连不上。
这不是 Runner 配置问题，是 GitLab 容器网络暴露策略没调对。Docker 的 -p 80:80 只把宿主机 80 映射到容器 80，但 GitLab 内部服务（如 API）仍默认绑定 127.0.0.1，不响应来自宿主机的连接请求。
- 必须在
GITLAB_OMNIBUS_CONFIG中强制指定监听地址：nginx['listen_addresses'] = ["0.0.0.0"]（不要留127.0.0.1） - 若用了 HTTPS，还需加：
nginx['ssl_listen_addresses'] = ["0.0.0.0"]，否则443端口照样不对外 - Runner 注册时 URL 必须填宿主机可访问的地址（如
http://localhost或https://gitlab.example.com），绝不能填http://127.0.0.1或容器 IP
GitLab 升级后 500 错误，日志里反复出现 NoMethodError: undefined method `[]' for nil:NilClass
升级镜像版本（如从 16.9 到 16.11）后，首页直接 500，docker logs 里看到大量 Ruby 异常堆栈，末尾指向 app/models/concerns/has_layout.rb —— 这是 GitLab 升级过程中数据库迁移没跑完，或者旧版缓存未清除导致的元数据不一致。
Omnibus 版本升级不是简单替换镜像，它依赖 gitlab-ctl upgrade 触发迁移脚本；Docker 镜像直接换 tag 会跳过这步，残留旧 schema 和新代码，必然崩。
- 升级前先停老容器：
docker stop <old_container>，但**不要删卷**（尤其是/var/opt/gitlab） - 用新镜像启动临时容器，挂载原有卷，手动执行：
docker run --rm -v /path/to/gitlab/config:/etc/gitlab -v /path/to/gitlab/logs:/var/log/gitlab -v /path/to/gitlab/data:/var/opt/gitlab gitlab/gitlab-ce:16.11.0 gitlab-ctl upgrade - 确认输出含
Database migrations complete后，再用新镜像启正式容器；升级后首次启动耗时明显更长，这是正常现象
最麻烦的点其实是卷权限：GitLab 16+ 要求 /var/opt/gitlab 所有者是 git:root，但旧版可能属 root:root，升级时 gitlab-ctl upgrade 会静默失败，得先 chown -R git:root /path/to/gitlab/data。
