CORS error with nginx reverse proxy

[Sharpie171]

I have followed the setup in the Readme a few times. I have redacted my domain to use example.com in this issue.

When I attempt to register a new user, a CORS error occurs because the application attempts to reach https://example.com/api/auth/account/create? instead of https://stoat.example.com/api/auth/create?

Can I correct the CORS request so that it uses the stoat.example.com subdomain with the configs?

My configuration files follow, using example.com instead of my real domain:

Here is my nginx config, it contains other configuration for subdomains to other self-hosted applications so it doesn't make sense to handle stoat traffic through the regular https://example.com

# nginx.conf
http {
    server {
        server_name example.com;
        listen 443 ssl; 
        # Certbot SSL configuration
    }
    # Jellyfin
    server {
        listen 443 ssl;
        server_name jellyfin.example.com;
        # Jellyfin Reverse Proxy config
        }
    # Taiga
    server {
        listen 443 ssl;
        server_name taiga.example.com;
        # Taiga Reverse Proxy config
        }
    # Stoat
    server {
        listen 443 ssl;
        server_name stoat.example.com;
        location / {
            allow all;
            proxy_pass http://localhost:8880;
            proxy_set_header Host $server_name;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }

        location /ws {
            allow all;
            proxy_pass http://localhost:8880;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_set_header Host $server_name;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }

        location /livekit {
            allow all;
            proxy_pass http://localhost:8880;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_set_header Host $server_name;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }
}

Here is my .env.web file, it hasn't been changed after running ./generate_config.sh:

# .env.web
HOSTNAME=:80
REVOLT_PUBLIC_URL=https://stoat.example.com/api
VITE_API_URL=https://stoat.example.com/api
VITE_WS_URL=wss://stoat.example.com/ws
VITE_MEDIA_URL=https://stoat.example.com/autumn
VITE_PROXY_URL=https://stoat.example.com/january

I have pretty old hardware (the CPU I have is from 2008) so I had to alter the compose.yml file to use docker images that my old hardware can handle. Could this be the cause of the issue? Below are the changes from the standard compose.yml

# compose.yml (changes only)
services:
  # MongoDB: Database
  database:
    image: docker.io/mongo:4.4
    restart: always
    volumes:
      - ./data/db:/data/db
    healthcheck:
      test: echo 'db.runCommand("ping").ok' | mongo localhost:27017/test
      interval: 10s
      timeout: 10s
      retries: 5
      start_period: 10s

  # Redis: Event message broker & KV store
  redis:
    image: docker.io/eqalpha/keydb:x86_64_v6.3.3
    restart: always
  # MinIO: S3-compatible storage server
  minio:
    image: docker.io/minio/minio:RELEASE.2025-09-07T16-13-09Z-cpuv1
    command: server /data
    volumes:
      - ./data/minio:/data
    environment:
      MINIO_ROOT_USER: minioautumn
      MINIO_ROOT_PASSWORD: minioautumn
      MINIO_DOMAIN: minio
    networks:
      default:
        aliases:
          - revolt-uploads.minio
          # legacy support:
          - attachments.minio
          - avatars.minio
          - backgrounds.minio
          - icons.minio
          - banners.minio
          - emojis.minio
    restart: always
  # Caddy: Web server
  caddy:
    image: docker.io/caddy
    restart: always
    env_file: .env.web
    ports:
      - "80:80"
      # - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - ./data/caddy-data:/data
      - ./data/caddy-config:/config

[b0BcAtT4T]

Are you using NGINX or NGINX PROXY MANAGER?

If it’s NPM just enable websockets toggle and don’t worry about the nginx.conf or the advance field - leave it all empty.

[b0BcAtT4T]

Oh also, your caddy in the compose.yml is running on port 80, that’s the port nginx should be running on so change it to “9009:80” for example, or any other port you’d like, then point nginx at caddy.

[Sharpie171]

@b0BcAtT4T Thanks for the info. No, I am not using Nginx Proxy Manager. I am apparently somehow allergic to doing things the easy way.

I believe the config setup for Caddy would be true, however, the ./generate_config.sh creates (or at least modifies) a file called compose.override.yml that I forgot to mention. That file contains this information

# compose.override.yml
services:
  caddy:
    ports: !override
     - "8880:80"

Based on your information, this should mean I can point nginx to http://localhost:8880 as is in my nginx file above. I believe this override is working, sort of, because I can go to my https://stoat.example.com address and I don't receive any errors until it tries to call the api. By no errors, I mean there isn't a 502 bad gateway error, which I can recreate if I change the contents of compose.override.ymll to have 9009:80 as the ports, since my nginx config is not pointing at 9009, it is pointing to 8880.

There must be some sort of additional setup I have to do in the nginx file, but I'm not sure what that is.

[b0BcAtT4T]

@Sharpie171 Ah that makes sense, I think the override stuff is new, so I have no idea in this case.
The only thing I can recommend is to use NPM and if that doesn't work perhaps there is something wrong with the new ./generate_config.sh?
I had the same login issues when I was trying to remove caddy and just use NPM so similar to your line or reasoning I would be looking at the reverse proxy.

[Dadadah]

Can you post your Revolt.toml (with secrets removed)?

[Sharpie171]

@Dadadah I haven't customized the Revolt.toml beyond what the generate_config.sh file might have done. Here is mine.

#Revolt.toml
[hosts]
app = "https://stoat.example.com"
api = "https://stoat.example.com/api"
events = "wss://stoat.example.com/ws"
autumn = "https://stoat.example.com/autumn"
january = "https://stoat.example.com/january"

[hosts.livekit]
worldwide = "wss://stoat.example.com/livekit"

[pushd.vapid]
private_key = <redacted>
public_key = <redacted>

[files]
encryption_key = <redacted>

[api.livekit.nodes.worldwide]
url = "http://livekit:7880"
lat = 0.0
lon = 0.0
key = <redacted>
secret = <redacted>

According to the documentation, I have also opened ports 7880/tcp and 50000:50100/udp in my firewall and have the port forwarding setup for those on my router.

[Dadadah]

If your web client is hitting the wrong domain, then it is misconfigured somewhere. I wonder if in your domain replacement, you are concealing the error?

If you are serving the web app on the right subdomain, but the rest of the requests are going to the base domain, that indicates that the web app is being given the wrong domains for it's config. This means either the hosts in Revolt.toml or the hosts in env.web are not correct. Did you run ./generate-config.sh with your fully qualified stoat domain name or your base domain?

[Sharpie171]

Yes, I called it with the fully qualified domain name.
./generate_config.sh stoat.example.com
It is possible that I have accidentally concealed the error, but I have been trying to be very careful not to do so.

Before I finally got to the login screen, I did call it with the incorrect domain like this:
./generate_config.sh example.com
And that didn't even get the login screen working. I then removed the stoat directory and started over:

cd stoat
docker compose down
cd ../
rm -rf ./stoat
git clone https://github.com/stoatchat/self-hosted stoat
cd stoat
chmod +x ./generate_config.sh
./generate_config.sh stoat.example.com
(yes when it asks about reverse proxy)

Is it possible that something from my first attempt is causing problems? Usually rm -rf is pretty thorough at cleaning things up.

[Dadadah]

you may try cleaning your cache for the site - the website might be storing the old urls

[Sharpie171]

And now I feel like an idiot! It's always something simple like the browser cache.
Thanks @Dadadah clearing the browser cache fixed it.