Immich API can connect remotely, not local
O canm reach my immich instance on two urls:
- remote https://photos.my-domain.com
- local https://photos.lan (functions perfectly fine and exactly like a remote domain, it has proper SSL etc, just that it is LAN)
The Immich CLI cannot connect to the local, it says
It works on remote url with exact same details but remote URL instead of LAN url
This is truly annoying since now:
- app does not work on large libs
- immich-go cannot read meta data half the time for some reason (perhaps outdated?) even if present, does not even consider sidecar files (or embedded metadata)
- immich cli requires me to log in remotely, resulting in a staggering 84 hours upload time, probably just to get a final result of "has issues"
How can i make it accept local url?
16 Replies
:wave: Hey @smileBeda,
Thanks for reaching out to us. Please carefully read this message and follow the recommended actions. This will help us be more effective in our support effort and leave more time for building Immich :immich:.
References
- Container Logs:
docker compose logs
docs
- Container Status: docker ps -a
docs
- Reverse Proxy: https://immich.app/docs/administration/reverse-proxy
- Code Formatting https://support.discord.com/hc/en-us/articles/210298617-Markdown-Text-101-Chat-Formatting-Bold-Italic-Underline#h_01GY0DAKGXDEHE263BCAYEGFJA
Checklist
I have...
1. :ballot_box_with_check: verified I'm on the latest release(note that mobile app releases may take some time).
2. :ballot_box_with_check: read applicable release notes.
3. :ballot_box_with_check: reviewed the FAQs for known issues.
4. :ballot_box_with_check: reviewed Github for known issues.
5. :ballot_box_with_check: tried accessing Immich via local ip (without a custom reverse proxy).
6. :ballot_box_with_check: uploaded the relevant information (see below).
7. :ballot_box_with_check: tried an incognito window, disabled extensions, cleared mobile app cache, logged out and back in, different browsers, etc. as applicable
(an item can be marked as "complete" by reacting with the appropriate number)
Information
In order to be able to effectively help you, we need you to provide clear information to show what the problem is. The exact details needed vary per case, but here is a list of things to consider:
- Your docker-compose.yml and .env files.
- Logs from all the containers and their status (see above).
- All the troubleshooting steps you've tried so far.
- Any recent changes you've made to Immich or your system.
- Details about your system (both software/OS and hardware).
- Details about your storage (filesystems, type of disks, output of commands like fdisk -l
and df -h
).
- The version of the Immich server, mobile app, and other relevant pieces.
- Any other information that you think might be relevant.
Please paste files and logs with proper code formatting, and especially avoid blurry screenshots.
Without the right information we can't work out what the problem is. Help us help you ;)
If this ticket can be closed you can use the /close
command, and re-open it later if needed.
Successfully submitted, a tag has been added to inform contributors. :white_check_mark:it has proper SSL etc,Are you sure about this? If it's literally a .lan domain it's impossible that can use proper TLS
yes I am sure about this
It is *not * a self-signed cert?
Because I use that lan every day, and also use it with immich-go using https
It is a self signed cert but the cert is accepted, no tool or browser (ssh, etc etc) will ever complain
I mean, it is downloaded
not "accept risk" kind of thing, but actually stored in my client computer
Idk how fetch in node works but it's possible it's not using the local keystore I guess
Either way using your public domain shouldn't take any longer. If you don't have split DNS set up your router will do hair pin NAT, that is, it'll reach the router, realize it's pointing at its own address, and rewrite the request, sending it back immediately
Not sure how that would work, since it has to go to sweden to go through WireGuard and back into my home machine... no, remote URLs take a roundtrip, they are not "here"
Well, I probably could temporarily point it to local in my DNS...
but I prefer not to go there
“No tool will ever complain”: impossible and belies a lack of understanding in the SSL toolchain
Why wouldn’t you setup hairpin NAT or local DNS all the time?
I have a local DNS and that is what photos.lan is for
and it works with about every API I use.
Nevermind.
export NODE_EXTRA_CA_CERTS=/path/to/your-ca.pem
That’s not what local DNS is. You would use the same domain name that resolves locally
wheter I point the same domain to my local or another domain... is about the same
No, with one you have a proper cert with a globally trusted key chain
With the other you don't
So you would just point the real domain to your local, while inside your LAN?
I can of course do that, there are reasons why I do not (for example, I want the same experience as the "visitors" when I visit the real domain, for debug reasons etc, but in this case it is not that crucial)
Anyway,
export NODE_EXTRA_CA_CERTS=/path/to/your-ca.pem
seems to be the trickIf you want to debug your public domain switch to mobile data or something. But that's genuinely the only reason I can think of not to do split DNS
good luck debugging on a mobile.
For me there are more reasons to split domains (have two, one local, one real) for some services
Mainly, less headaches with dns mess
having two domains is like most straight forward, and as said, never caused an isue so far... seems node is a first.
Closing because export NODE_EXTRA_CA_CERTS=/path/to/your-ca.pem solves the issue
This thread has been closed. To re-open, use the button below.