Docker部署Gitea搭配Traefik基础认证时Git Push认证失败问题

• 当前push认证失败的核心是Traefik BasicAuth和Git原生认证机制存在请求头冲突：
  HTTP协议中单个请求仅能携带一个Authorization头，Traefik的BasicAuth中间件默认在完成代理层凭证校验后，会覆盖原始请求的Authorization头内容，再转发给后端Gitea服务。
  • git clone属于读操作，当目标仓库为公开权限时，Gitea不需要校验用户身份，因此即使收到的认证头是Traefik的代理凭证，也会放行请求，表现为输入Traefik BasicAuth凭证即可完成clone。
  • git push属于写操作，必须校验客户端携带的合法Gitea账号/令牌权限，此时Gitea收到的是被Traefik覆盖后的代理凭证，并非系统认可的有效用户凭证，因此会抛出invalid credentials的报错。
• 关闭Traefik BasicAuth后，请求的认证头不会被拦截篡改，Gitea可以正常识别客户端提交的原生凭证，因此clone和push都能正常运行。
• 之前单独配置DISABLE_REGISTRATION = true达不到访问控制效果，是因为该配置仅关闭了注册入口，默认Gitea还是会对未登录用户展示所有标记为公开的组织、仓库信息，外部人员可以随意浏览公开资源，甚至通过枚举仓库地址直接clone公开内容。

方案1：调整Traefik路由规则，分离Web访问和Git操作的校验逻辑 #

• 对当前配置改动最小，可快速修复push认证失败的问题：
  • 保留Traefik BasicAuth对Gitea Web界面的拦截，仅对所有匹配/.git/的Git操作路径排除BasicAuth校验
  • 被排除的Git请求直接转发给Gitea，由Gitea自身的权限体系完成认证校验
• 实现效果：
  无关人员打开Gitea域名时，首先被Traefik的BasicAuth拦截，只有持有Traefik凭证的人才能看到Gitea的Web登录页；Git操作请求不会被Traefik层拦截，直接走Gitea原生认证流程，输入Gitea账号凭证即可正常完成clone、push操作，彻底解决头冲突问题。
• 安全补全：
  启用该规则时需要同步开启Gitea的REQUIRE_SIGNIN_VIEW = true，确保绕过Traefik拦截的Git请求，也会被Gitea强制要求合法登录，不会出现权限漏空。

方案2：去掉Traefik层的BasicAuth，用Gitea原生能力实现「仅指定开发团队可访问」 #

• 是长期更稳定的方案，无两套凭证维护成本，也不会出现协议兼容问题：
  • 保留DISABLE_REGISTRATION = true配置，关闭公开注册入口，所有账号仅能由管理员在后台手动创建，外部用户无法自行注册进入系统
  • 开启REQUIRE_SIGNIN_VIEW = true，将Gitea站点设置为完全私有模式：所有页面、所有仓库资源，无论公开还是私有，未登录用户访问任何路径都会被强制跳转到登录页，看不到任何组织、仓库信息
• 实现效果：
  只有管理员手动创建的指定开发团队成员，才能用合法Gitea账号登录Web界面、执行Git操作；外部人员即使知道Gitea的域名，也因为没有合法账号，既进不去Web页面，也没法clone或push任何仓库资源，完全匹配访问控制需求。
• 相比Traefik BasicAuth的优势：
  • 无认证头冲突，Git操作稳定性高
  • 支持细粒度的权限分配，比如给不同团队成员分配不同仓库的读写权限
  • 不需要额外维护Traefik层的独立凭证，只需要管理Gitea本身的用户账号

方案3：必须保留全路径Traefik BasicAuth拦截时的适配方式 #

• 适合有统一身份认证要求的场景，小团队不推荐过度折腾：
  • 调整Traefik BasicAuth中间件配置，将removeHeader参数设置为false，避免中间件删掉原始请求的认证头
  • 配置Traefik将校验通过的用户身份通过自定义请求头（如X-Forwarded-User）转发给后端
  • 在Gitea中开启受信任反向代理配置，将自定义头传递的用户身份映射为Gitea的合法登录态，实现单点登录
• 该方案复杂度较高，需要维护两套认证逻辑的映射关系，适合有一定规模的团队使用。

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