Capistrano部署GitLab令牌认证失败：HTTP Basic访问被拒绝

针对更新GitLab Access Token后，Capistrano部署报HTTP Basic: Access denied但本地和服务器手动Git操作正常的情况，尝试以下解决方案：

• 清理服务器上的Git凭证缓存
  Capistrano默认使用远程缓存策略，服务器上的Git可能缓存了旧的认证信息。操作步骤：

  1. 登录部署服务器，切换到部署用户（如deploy）
  2. 进入应用的共享仓库目录，例如：cd /var/www/your_app/shared/repo
  3. 清除该仓库的凭证配置：git config --unset credential.helper
  4. 重新设置仓库地址：git remote set-url origin <你的新带token的HTTPS仓库地址>
     也可临时全局禁用凭证缓存：git config --global --unset credential.helper，测试部署后再按需恢复。

• 检查repo_url格式是否正确
  确保repo_url符合Git要求格式：https://<access_token>:@gitlab.com/your_namespace/your_repo.git

  • 注意token后的冒号和@符号不能省略，即使无密码字段
  • 若token包含特殊字符（如/、=、&），需进行URL编码，例如/替换为%2F，=替换为%3D

• 切换Capistrano的Git策略
  临时切换到克隆策略，强制每次部署重新克隆仓库，验证是否为缓存问题：
  在deploy.rb中添加：

  set :git_strategy, Capistrano::Git::CloneStrategy
  

  执行部署测试，成功后可切回默认的:remote_cache策略，并删除shared/repo缓存目录。

• 验证服务器Git版本兼容性
  旧版本Git对HTTPS凭证的处理可能存在bug，检查服务器Git版本：git --version
  若版本低于2.10，建议升级到2.18以上的稳定版本后再尝试部署。

• 排查Capistrano配置覆盖问题
  确保无其他配置覆盖repo_url：

  1. 检查stage配置文件（如config/deploy/staging.rb）是否重新定义了repo_url
  2. 执行部署时添加--trace参数：cap staging deploy --trace，搜索repo_url输出，确认实际使用的是新的带token地址

• 模拟Capistrano执行环境测试
  切换到Capistrano部署用户，在服务器上执行相同Git操作：

  git clone <新的repo_url> test_deploy
  cd test_deploy
  git remote update
  

  若操作成功，说明Capistrano执行环境存在差异，比如用户权限、环境变量问题，需检查部署脚本中是否有sudo切换用户或修改环境变量的逻辑。

内容的提问来源于stack exchange，提问作者Chris