Immich fails to adapt when server address changes behind a redirect domain

[yvfx]

I have searched the existing issues, both open and closed, to make sure this is not a duplicate report.

• Yes

The bug

Hi, thanks for the great project!

Problem

When accessing the server through a redirect domain (e.g. .well-known/immich returns a different hostname/port), Immich resolves and caches the real address at login. All subsequent requests go directly to the cached address, bypassing the original domain. Once the real address changes (e.g. dynamic port from NAT traversal), the cache becomes stale, the app cannot connect, and backups repeatedly fail until it crashes.

My attempt

I tried using Automatic Endpoint Switching in the app settings, adding the redirect domain as an external endpoint so the app would re-resolve on each resume and pick up the new address. But the validation always fails (red exclamation mark) and the configuration cannot be saved.

The reason: validation first resolves the real address via .well-known/immich, then sends GET /users/me to that address. However, auth cookies are bound to the original input domain and don't carry over to the resolved domain, so the request arrives unauthenticated and fails.

The OS that Immich Server is running on

Linux (Docker)

Version of Immich Server

v3.0.1

Version of Immich Mobile App

v3.0.0 build.7

Platform with the issue

• Server
• Web
• Mobile

Device make and model

iphone13

Your docker-compose.yml content

-

Your .env content

-

Reproduction steps

1. Set up a redirect domain (e.g. via Cloudflare Worker) that
   307-redirects all requests to the origin server (different
   hostname:port).

2. In the Immich mobile app, log in using the redirect domain URL.

3. After login, the app resolves and caches the real address
   (different host/port). All subsequent API calls go directly
   to the cached address, bypassing the redirect domain.

4. When backing up photos, iOS URLSession drops the POST body
   on 307 redirects. Combined with Cloudflare's 100MB request
   body limit, large file uploads fail. After repeated retries,
   the app crashes.

5. Switching the redirect to 302 fixes the crash and backups
   work normally, but the app still caches the resolved origin
   address (including port) permanently.

6. When the origin port changes (e.g. NAT traversal reassigns
   a new port), the app continues using the old cached address,
   cannot connect, and backups fail.

7. (Endpoint Switching attempt) Go to Settings → Network, enable
   Automatic Endpoint Switching, and add the redirect domain as
   an external endpoint. Validation always fails (red exclamation
   mark) and the configuration cannot be saved. Reason: validation
   resolves the URL via /.well-known/immich to a different origin,
   then sends GET /users/me to that origin — but auth cookies are
   bound to the input domain and don't carry over, so the request
   arrives unauthenticated (401).

Relevant log output

Additional information

No response

[mmomjian]

I’m going to leave this open for a chance for someone else to chime in but I view this as #15230. I don’t think we actually support what you are trying to do.

[mertalev]

I can say this is the first time I'm hearing about this use-case and I'm not sure it's something we should support. In any case, it's closer to a feature request than a bug in my eyes.

[yvfx]

Fair point, I can see this as a feature request rather than a bug.

The reason I bring it up is that the fix is minimal (one line, /users/me → /server/ping) and has no downside for existing users. /users/me doesn't add meaningful security over /server/ping for endpoint validation — a malicious server would return 200 on both. The only difference is /users/me blocks cross-origin setups.