Redirect loop for initial password change, behind nginx SSL reverse-proxy

Hi there, I’m successfully running Gitea in the following setup:

  • On a server with a static IP only (no domain name)
  • In a subdirectory (at /git)
  • Behind an nginx reverse-proxy which handles SSL encryption
  • Everything in Docker (nginx and Gitea in separate containers) under the same network

The only problem I have is when creating a new user with the option “Require user to change password”. The user can log in, but when trying to do anything, he is redirected to /git/user/settings/change_password and just sees an ERR_TOO_MANY_REDIRECTS.

Nginx redirects all HTTP requests to HTTPS:

server {
  listen 80;
  return 301 https://$host$request_uri;

Then, proxying the incoming HTTPS requests to Gitea:

server {
  listen 443 ssl;
  # certificate, SSL configuration, ...

  location /git/ {
    proxy_pass http://git_server:3000/ # git_server is the name of the docker-compose service

I feel like Gitea redirects to the HTTP version of the change_password URL, but gets a request coming from the HTTPS version and thus redirects it to HTTP again. But I have no idea how to proof / track this nor how to resolve it. (I’m new to almost every aspect of this setup…)

In Gitea’s app.ini I tried both http and https as protocol prefixes for the ROOT_URL. I also tried adding a proxy_redirect http:// https://; in the nginx config. Neither changed anything. Do I need to somehow rewrite header information to make Gitea believe its redirect worked?

Thanks for any help!


@asprionj Did you ever fix this issue? I’m having the same problem.

Nope, haven’t solved it. The quick & dirty fix is to just deactivate the option Require user to change password when creating new user accounts.

The problem (with this problem :wink: ) is that it probably emerges from the combination of the NGINX reverse-proxy with Gitea and does not occur otherwise. This fact makes it hard to pinpoint the problem.

This patch from this PR solves the issue for me