ZitatAlso z.B. wie ist der container fhempi mit dem Host verbunden?
Ich habe mit Docker ehrlich gesagt noch zu wenig Erfahrung, um die geforderten Details zur Container-Anbindung auf Anhieb liefern zu können, beschäftige mich damit aber und reiche die Infos ggf. nach.
Inzwischen habe ich festgestellt, dass das Problem identisch auch bei FHEM oder anderen Anwendungen auftritt, also unabhängig von Docker. Der Zugriff über die IP-Adresse funktioniert immer, betroffen ist ausschließlich der Hostname.
Daher gehe ich aktuell davon aus, dass es nicht direkt mit Docker zusammenhängt.
Das hier hat nichts mit Docker zu tun.
Die Hostnamen von Docker sind immer nur über den Docker DNS-Resolver verfügbar und dieser ist nur innerhalb der Container verfügbar! (Der Resolver läuft innerhalb der Container über 127.0.0.11, ist für dieses Problem jetzt aber völlig ohne Belang).
Auf dem Host selbst sind die Hostnamen der Container nicht auflösbar, genausowenig durch andere Geräte im Netzwerk.
Das hier ist aber ohnehin kein Hostname des Containers, also vergiss (für die Beantwortung dieser Frage) einfach alles, was ich über Docker gesagt habe.
Hier hast du einfach lokal auf deinem System deinem Pi den Hostnamen "fhempi" zugewiesen, deshalb auch der Eintrag in der /etc/hosts-Datei (siehe hier (https://serverfault.com/a/793272)).
Deshalb klappt vom Pi aus dieser Befehl auch immer
Zitat von: TomLee am 09 Februar 2026, 18:08:46curl --head --insecure https://fhempi
weil der Pi selbst (zuerst) in seiner /etc/hosts-Datei nachschaut und herausfindet, dass der Hostname fhempi zu 127.0.1.1 (Loopback-Interface) führt und dieses dann anfragt.
Andere Geräte haben diesen Eintrag in ihrer /etc/hosts-Datei (sofern es eine gibt) aber nicht,* fragen deshalb den per DHCP oder sonst konfigurierten DNS-Resolver an (meist deinen Router, der wiederum normalerweise den DNS-Resolver deines ISP anfragt) und weil fhempi keine ordentlich irgendwo registrierte Domain ist, gibts dazu auch keinen DNS-Eintrag, der auf irgendeine IP verweisen kann. Deshalb klappt dann die Abfrage per Hostnamen auch nicht.
Das gilt übrigens auch für Docker-Container, auch die haben eine eigene /etc/hosts und sehen nicht die /etc/hosts des Docker-Hosts. Abgesehen davon würde ein striktes 1:1-Mapping der Docker-Host-/etc/hosts in die Docker-Container-/etc/hosts auch nichts bringen, weil die Container (sofern nicht network_mode host genutzt wird) jeweils eigene Netzwerkinterfaces haben, sodass das unter * Gesagte gilt.
*Wichtig ist, dass der Eintrag 127.0.1.1 sowieso komplett nutzlos für die anderen Geräte wäre, weil das ja nicht die LAN-IP deines Pi ist; der Request von cURL geht also gar nicht ins LAN, sondern bleibt auf dem Loopback-Interface. Der Hostname fhempi darf sich also, damit er nützlich für andere Computer im Netzwerk ist, nicht zu 127.0.1.1 auflösen. Dann würden die nämlich nur einen Request zu ihrem
eigenen Loopback-Interface machen und nicht über das LAN zu deinem Pi.
Soweit jedenfalls die Theorie.
Was jetzt aber häufig passiert, ist, dass sich Geräte per DHCP unter ihrem Hostnamen anmelden und der DHCP-Server, der auf dem Router läuft, im DNS-Resolver, der ebenfalls auf dem Router läuft, einen Eintrag zu der jeweiligen IP-Adresse hinterlegt und zwar mit dem Hostnamen, mit dem sich die Geräte per DHCP angemeldet haben.
Dann spart man sich das manuelle Konfigurieren der DNS-Einträge fürs Heimnetzwerk und kann die Geräte, so wie du es willst, einfach mit ihrem Hostnamen aufrufen. Macht allen voran die Fritzbox so, teilweise auch mit $HOSTNAME.fritz.box. (Bin mir grade nicht sicher, ob das fritz.box zwingend erforderlich ist, oder nur $HOSTNAME reicht.)
Mit ziemlciher Sicherheit wird das auch bei dir so sein, dass dein Pi beim DHCP-Request nach dem Booten seinen Hostnamen mitschickt und dann ein DNS-Eintrag gesetzt wird. Vermutlich ist es jetzt so, dass dein Router so eingestellt ist, dass die DHCP-Lease nach 24 Stunden abläuft und damit eben auch der DNS-Eintrag. Und dann schlägt die Namensauflösung fehl.
Aus irgendeinem Grund sendet dein Pi also nicht wiederholt DHCP-Renew Anfragen an den DHCP-Server, sodass die Lease abläuft.
Deshalb:
- Hast du für den Pi im Pi selbst eine statische IP konfiguriert?
- Oder bekommt er eine statische IP vom DHCP-Server?
- Läuft auf dem Pi der DHCP-Client? (Unter Raspbian dhclient, glaube ich, aber nicht sicher.)
- Steht irgendwas DHCP-bezogenes im Syslog vom Pi unmittelbar nach dem Booten?
- Steht irgendwas DHCP-bezogenes im Syslog vom Pi nach 24 Stunden uptime?
- Was gibt sudo ss -tulpn zurück? (siehe unten)
Sorry, ist jetzt vielleicht ein bisschen durcheinander alles, feel free, das in irgendein LLM deiner Wahl zu werfen, damit es besser strukturiert und verständlicher wird.
Übrigens: Es gibt auch noch sowas wie mDNS, das könnte hier theoretisch auch noch eine Rolle spielen, aber wage ich prinzipiell mal zu bezweifeln. Wobei es durchaus sein könnte, je nach dem, was das für eine Anwendung ist, die da läuft. Typischerweise funktioniert mDNS aber mit *.local-Adressen, die benutzt du hier ja nicht. Gib uns der Vollständigkeit halber vielleicht trotzdem mal die Ausgabe von
sudo ss -tulpn, dann sehen wir, ob da irgendwas mDNS-mäßiges läuft (UDP-Port 5353) (und, wie mir grade auffällt auch, ob der DHCP-Client läuft (UDP-Port 68)).