config: 0.0.0.0 als Vorgabe für APP_BIND im Betrieb

Auf Marcs Wunsch. Die bisherige Vorgabe 127.0.0.1 passt nur, wenn der
Reverse Proxy auf demselben Rechner läuft – steht er woanders (bei Marc
auf einem VPS), kommt er an loopback gar nicht heran, und die Vorgabe war
schlicht der falsche Wert für den häufigeren Fall.

Der Preis steht jetzt an allen drei Stellen dabei, statt nur gemeint zu
sein: Der Port ist dann auch aus dem eigenen Netz offen, und TLS endet
erst am Proxy. Im README dazu eine Tabelle, welcher Wert zu welchem
Aufbau gehört – eigener Rechner, anderer Rechner, Tunnel, oder Proxy im
selben Docker-Netz (dann braucht es gar kein ports:).

build/docker-compose.yml behält 127.0.0.1: Das ist die
Entwicklungsumgebung auf diesem Rechner, dort ist loopback richtig.

Gegengeprüft: Frische Kopie aus den Beispieldateien veröffentlicht auf
0.0.0.0; APP_BIND=127.0.0.1 in der .env engt wieder auf loopback ein.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.env.example

@@ -52,9 +52,17 @@ ADMIN_PASSWORD=
 TRUSTED_PROXIES=172.18.0.1
 # Port auf dem Wirt. Im Container bleibt es 8080.
 APP_PORT=8080
-# Wer den Port erreichen darf. 127.0.0.1 = nur dieser Rechner (Vorgabe, davor
-# gehört der Proxy). 0.0.0.0 = das ganze Netz – dann unverschlüsselt.
-APP_BIND=127.0.0.1
+# Wer den Port erreichen darf.
+#   0.0.0.0    alles, was den Server im Netz erreicht (Vorgabe)
+#   127.0.0.1  nur dieser Rechner – richtig, wenn der Reverse Proxy hier läuft
+#   10.0.0.5   eine bestimmte Adresse, etwa das Ende eines WireGuard-Tunnels
+#
+# Die Vorgabe ist 0.0.0.0, weil der Proxy typischerweise woanders steht und
+# 127.0.0.1 ihn gar nicht erst herankommen ließe. Der Preis: Der Port ist auch
+# aus dem eigenen Netz offen, und TLS endet erst am Proxy – bis dahin liegt die
+# Anmeldung unverschlüsselt im Netz. Wer den Proxy auf demselben Rechner hat,
+# setzt hier 127.0.0.1 und ist besser dran.
+APP_BIND=0.0.0.0
 APP_LISTEN_ADDR=:8080           # im Container; der Proxy leitet hierher
 
 # ══ Sitzung ═══════════════════════════════════════════════════════════════════

README.md

@@ -235,12 +235,27 @@ selbst anlegst (PocketID, Authentik); bei freier Registrierung wäre es die
 Übernahme fremder Konten. Verbunden wird ohnehin nur, was noch keine Bindung
 hat.
 
-**`APP_BIND`** entscheidet, wer den Port überhaupt erreicht. Die Vorgabe
-`127.0.0.1` heißt: **nur dieser Rechner.** Von einem anderen Gerät kommt dann
-kein Zeitüberlauf, sondern sofort `ERR_CONNECTION_REFUSED` – der Kernel lehnt
-ab, bevor irgendetwas die Anwendung erreicht. Das ist Absicht: Davor gehört
-dein Reverse Proxy mit TLS. Zum Ausprobieren im eigenen Netz `APP_BIND=0.0.0.0`
-setzen – dann geht die Anmeldung allerdings unverschlüsselt über das Netz.
+**`APP_BIND`** entscheidet, wer den Port überhaupt erreicht. Der richtige Wert
+hängt davon ab, **wo dein Reverse Proxy steht:**
+
+| Proxy läuft … | Wert |
+|---|---|
+| auf einem anderen Rechner (VPS, Router) | `0.0.0.0` – die Vorgabe |
+| hinter einem Tunnel (WireGuard, Tailscale) | die Tunnel-Adresse, z. B. `10.0.0.5` |
+| auf demselben Rechner | `127.0.0.1` |
+| als Container im selben Docker-Netz | dann braucht es `ports:` gar nicht – der Proxy erreicht `app:8080` intern |
+
+`127.0.0.1` heißt **nur dieser Rechner**: Von einem anderen Gerät kommt kein
+Zeitüberlauf, sondern sofort `ERR_CONNECTION_REFUSED` – der Kernel lehnt ab,
+bevor irgendetwas die Anwendung erreicht. Wer den Proxy daneben stehen hat,
+sollte genau das nehmen.
+
+Die Vorgabe ist trotzdem `0.0.0.0`, weil der häufigere Fall ein Proxy auf einem
+anderen Rechner ist, den loopback gar nicht erst herankommen ließe. Was das
+kostet, damit es niemanden überrascht: Der Port ist dann auch aus dem eigenen
+Netz offen, und **TLS endet erst am Proxy** – auf dem Weg dorthin liegt die
+Anmeldung unverschlüsselt im Netz. Wer das nicht will, engt den Wert ein oder
+lässt nur den Proxy durch die Firewall.
 
 **`DATA_PATH`** ist ein gewöhnliches Verzeichnis auf dem Wirt, kein
 Docker-Volume – deshalb kommst du per SFTP, rsync oder im Dateimanager daran.
@@ -558,7 +573,7 @@ entsteht der Container dann nie, ohne jede Fehlermeldung.
     cap_add: [MKNOD]
     networks: [internal]
     ports:
-      - "${APP_BIND:-127.0.0.1}:9980:9980"
+      - "${APP_BIND:-0.0.0.0}:9980:9980"
 ```
 
 ```env
@@ -606,7 +621,7 @@ OFFICE_ALLOWED_HOSTS=office
       JWT_SECRET: ${OFFICE_JWT_SECRET}
     networks: [internal]
     ports:
-      - "${APP_BIND:-127.0.0.1}:9980:80"   # OnlyOffice lauscht auf 80, nicht 9980
+      - "${APP_BIND:-0.0.0.0}:9980:80"   # OnlyOffice lauscht auf 80, nicht 9980
 ```
 
 ```env
@@ -638,7 +653,7 @@ heißen gleich. Für uns ist es deshalb **derselbe Anbieter** –
       ALLOW_PRIVATE_IP_ADDRESS: "true"  # es muss app:8080 erreichen
     networks: [internal]
     ports:
-      - "${APP_BIND:-127.0.0.1}:9980:80"
+      - "${APP_BIND:-0.0.0.0}:9980:80"
 ```
 
 Die `.env` ist dieselbe wie bei OnlyOffice. Rechne mit **5 GB** allein für das

docker-compose.example.yml

@@ -41,10 +41,12 @@ services:
       - ${DATA_PATH:-./data}:/data
     networks: [internal]
     ports:
-      # Standardmäßig nur loopback – davor gehört dein Reverse Proxy mit TLS.
-      # Zum Ausprobieren im LAN: APP_BIND=0.0.0.0 in der .env. Dann liegt die
-      # Anmeldung allerdings unverschlüsselt im Netz.
-      - "${APP_BIND:-127.0.0.1}:${APP_PORT:-8080}:8080"
+      # Vorgabe 0.0.0.0: erreichbar für alles, was den Server im Netz sieht –
+      # denn der Reverse Proxy steht meist auf einem anderen Rechner, und
+      # loopback ließe ihn nicht heran. Davor gehört er trotzdem, mit TLS.
+      # Läuft er auf DIESEM Rechner: APP_BIND=127.0.0.1 in der .env, dann ist
+      # der Port von außen dicht.
+      - "${APP_BIND:-0.0.0.0}:${APP_PORT:-8080}:8080"
 
   postgres:
     container_name: aether-db