Suddenly Homarr container points at hostname:port instead of local IP:port, breaking proxy

[janaxhell]

Environment

Docker

Version

0.15.7

Describe the problem

I've been using Homarr for about 2 years now as docker container. With the following compose, it automatically pointed at 192.168.1.168:7575, which is the IP of the Orange Pi 3 LTS on which it's running. Suddenly it started pointing at http://orangepi3-lts:7575, breaking the proxying in Nginx Proxy Manager. All other services on the same machine point at the IP, Homarr doesn't. What can I do to fix it?

EDIT: To my surprise, after several failed connections, Homarr is now proxied to my tld, despite NPM being set to IP and Homarr using "orangepi3-lts".

Logs

services:
  homarr:
    container_name: homarr
    image: ghcr.io/ajnart/homarr:latest
    network_mode: "host"
    restart: unless-stopped
    volumes:
     - /srv/dev-disk-by-uuid-aeae213f-8ce4-405c-9d96-db90e69c28f8/Config/homarr/configs:/app/data/configs
     - /srv/dev-disk-by-uuid-aeae213f-8ce4-405c-9d96-db90e69c28f8/Config/homarr/icons:/app/public/icons
     - /srv/dev-disk-by-uuid-aeae213f-8ce4-405c-9d96-db90e69c28f8/Config/homarr/data:/data
     - /var/run/docker.sock:/var/run/docker.sock
    ports:
      - '7575:7575'

Context

Exporting hostname...
Migrating database...
yarn run v1.22.19
$ tsx ./migrate.ts
Done in 2.25s.
Starting production server...
Listening on port 7575 url: http://orangepi3-lts:7575
Warning: data for page "/board" is 155 kB which exceeds the threshold of 128 kB, this amount of data can reduce performance.
See more info here: https://nextjs.org/docs/messages/large-page-data
ℹ Local icons repository directory exists and contains 80 icons

Please tick the boxes

• [X] I confirm that I attached the proper logs
• [X] I've read the docs
• [X] I've checked for duplicate issues
• [X] I've tried to debug myself

[SeDemal]

Did you recently perform an update of homarr? Otherwise the issue may lie somewhere else.

Maybe it has to do to you using (or lack of use of) the env var "NEXTAUTH_URL"

[janaxhell]

I let Watchtower take care of updates, so I don't know if it's related. I do not use NEXTAUTH_URL BTW as I wrote, it somehow works, seems NPM understands that orangepi3-lts means 192.168.1.168 and lets me reach it via Cloudflare tld.

[SeDemal]

orangepi3-lts most likely is being translated to "localhost" in your host file in some capacity, or docker networking is setting that up. If Homarr is indeed being proxied, is there still a problem in functionality? I personally don't really look that much into what's written in that part of the log, my own instance has a random set of characters that mean nothing and change at every restart, yet my proxy manager handles it without issue.

[janaxhell]

orangepi3-lts is the name I assigned to the machine when I installed Open Media Vault on it, I don't know how OMV manages localhost names. Anyway no, the problem vanished on its own, this can be closed. The only thing that worries me a bit is: Warning: data for page "/board" is 155 kB which exceeds the threshold of 128 kB, this amount of data can reduce performance.

My Homarr is actually quite slow, especially when enabling config mode to add/remove apps. Can I do anything to mitigate that?

[SeDemal]

Great to hear that then.

For this part with the warning, this means you've created quite the heavy board with tons of things on it. The message is quite straightforward, there's so much on it that it gets slower. One thing that I could recommend is making multiple boards with a bookmark widget that links them between each other.

I think this issue may get mitigated in V1.0, but it would be interesting to see how V1.0 handles a config this big. If you're interested in helping, you can join our discord and join the insiders and early adopters.

[janaxhell]

Ah, I see, no I don't think I'll multiply boards, the whole point is to have everything in one place. I'll resist until 1.0. For what's worth, this is my board

[SeDemal]

goodness that's a lot of apps. One thing that slows the page load time a lot is actually the ping function, also to be improved in V1.0. Out of curiosity, could you turn off pings and try to reload? See if load time diminishes.

And if some of your apps don't need a status check, I'd recommend moving them to a bookmark widget instead. It's a neat way to make a list of apps take a lot less space. (It supports titles so you wouldn't need to put them in categories anymore either)

[janaxhell]

Yes, disabling pings made it snappier for sure, I tried Edit mode and clicking the cogwheel on apps made the settings dialog appear immediately. It took 10-15 secs before. I will try to do what you say with bookmarks, never thought about it, I have indeed links that are set as apps, just for habit. Thanks for the advice.