gitlab部署失败八成卡在gitlab-ctl reconfigure，主因是硬件不达标（需4核8g）、external_url设为localhost、基础服务未启用或selinux策略加载失败；应先检查资源、服务状态、配置合法性及防火墙端口。
gitlab-ctl reconfigure 卡住，八成不是安装命令写错了，而是系统没达标或配置写死了 localhost。别急着重装，先按这几步查。
检查硬件和基础服务是否就绪
GitLab 不是轻量工具，硬性门槛必须满足：4 核 CPU + 8GB 内存（free -h 看可用内存 ≥ 6GB），磁盘剩余 ≥ 20GB。低于这个规格，gitlab-ctl reconfigure 很可能卡在 PostgreSQL 启动或 Sidekiq 初始化阶段，日志里常出现 timeout waiting for postgresql 或 sidekiq not responding。
-
systemctl is-active postfix必须返回active；若不是，运行sudo systemctl start postfix && sudo systemctl enable postfix -
systemctl is-enabled sshd应输出enabled；否则执行sudo systemctl enable --now sshd - CentOS/RHEL 用户务必确认已安装
policycoreutils-python-utils（非policycoreutils-python），缺它会导致 SELinux 模块加载失败，reconfigure直接报错
external_url 绝不能写 localhost 或 127.0.0.1
这是部署失败最常见原因。GitLab 的 Nginx 和 Workhorse 组件用external_url 构造所有重定向、静态资源路径和 API 基地址。写成 "http://localhost" 或 "http://127.0.0.1:8080"，浏览器登录后会跳转到你本机，而不是服务器。
- 正确写法示例：
external_url "@#@#@#@#@#@#@#@#@#@0"（局域网 IP）、external_url "@#@#@#@#@#@#@#@#@#@1"（域名） - 改完必须运行
sudo gitlab-ctl reconfigure，只restart没用 - 如果走 HTTPS，还得同步设
nginx['redirect_http_to_https'] = true，并指定证书路径，否则 80 端口会陷入 301 循环
防火墙端口要显式放行，不能只开 “http” 服务
GitLab 默认监听 80（HTTP）、443（HTTPS）、22（SSH），但很多教程用firewall-cmd --add-service=http 是不够的——它不等价于开放 80 端口，尤其在某些 firewalld 版本下会失效。
- CentOS/RHEL：
sudo firewall-cmd --permanent --add-port=80/tcp、--add-port=443/tcp、--add-port=22/tcp，再sudo firewall-cmd --reload - Ubuntu/Debian（ufw）：
sudo ufw allow 80、sudo ufw allow 443、sudo ufw allow 22 - 注意：GitLab 内部还依赖 Unix socket 和 8080 端口（Workhorse），这些不用对外暴露，但别在 iptables 里误拦本地通信
初始密码在哪？别瞎猜 root / 5iveL!fe
安装完成后，GitLab 不会弹窗或打印默认密码。/etc/gitlab/initial_root_password 文件首行就是明文密码（仅首次生成，重装后才会更新）。如果文件不存在，说明 reconfigure 没跑完或失败了——得回去看日志，而不是试各种默认口令。
- 运行
sudo cat /etc/gitlab/initial_root_password 2>/dev/null | head -n1直接取密码 - 密码只保留 24 小时，登录后必须立即改掉
- 如果忘了删该文件，后续重装可能复用旧密码，造成权限混乱
真正卡点从来不在“怎么装”，而在“装之前有没有让系统真正准备好”。gitlab-ctl reconfigure 是个黑盒，但它报错前其实都留了线索——关键是你愿不愿意去 /var/log/gitlab/ 里翻那几行带 timestamp 的日志。
