diff --git a/REGISTRY.md b/REGISTRY.md
index 6c24049..5ccba84 100644
--- a/REGISTRY.md
+++ b/REGISTRY.md
@@ -59,6 +59,20 @@ curl -sS -D - -o /dev/null https://git.jfritzsche.de/v2/
 
 Ohne Anmeldung ist HTTP 401 normal. Der `WWW-Authenticate`-Header muss als Bearer-Realm **`https://git.jfritzsche.de/v2/token`** nennen. Ein HTTP-Realm kann den Upload mit `authorization server did not include a token in the response` scheitern lassen, obwohl `docker login` erfolgreich erschien. Keine HTTP-/TLS-Ausnahmen als Ersatz einrichten. Nach Korrektur den fehlgeschlagenen `publish`-Job erneut starten; dafür weder einen Release-Tag verschieben noch die Anwendung neu versionieren.
 
+### Upload scheitert mit HTTP 413 von Cloudflare
+
+Enthält die Fehlerantwort beim Push einer Image-Schicht `413 Payload Too Large` und den HTML-Absender `cloudflare`, blockiert Cloudflare den Upload. Eine funktionierende Registry-Anmeldung und ein korrekter HTTPS-Realm schließen diesen Fehler nicht aus. Cloudflare begrenzt einzelne Upload-Anfragen je Tarif, bei Free/Pro auf 100 MB; kleinere konfigurierte Grenzwerte sind ebenfalls möglich. Siehe [Cloudflare: Error 413](https://developers.cloudflare.com/support/troubleshooting/http-status-codes/4xx-client-error/error-413/).
+
+Für große Registry-Uploads kann `git.jfritzsche.de` als **DNS only** (graue Wolke) betrieben werden. **Vor der Umstellung** muss Dokploy/Traefik die Domain selbst auf Port 443 mit einem öffentlich vertrauenswürdigen Zertifikat, etwa von Let's Encrypt, bedienen. Ein reiner HTTP-Router auf `web` reicht nicht. Ein nur von Cloudflare vertrautes Origin-CA-Zertifikat reicht für direkte Docker-Clients ebenfalls nicht. Die direkte Erreichbarkeit des Origins muss zur Firewall-Konfiguration passen. Die Umstellung betrifft auch die Gitea-Weboberfläche auf derselben Domain.
+
+Vorher von außerhalb des Servers mit dessen tatsächlicher öffentlicher IP prüfen:
+
+```bash
+curl --resolve git.jfritzsche.de:443:SERVER_IP -sS -D - -o /dev/null https://git.jfritzsche.de/v2/
+```
+
+Erwartet: erfolgreiche TLS-Prüfung ohne `-k`, HTTP 401 und HTTPS-Bearer-Realm. Erst danach den DNS-Proxy abschalten, die DNS-Auflösung abwarten und den fehlgeschlagenen Publish-Job erneut starten. Keine Änderung von ROOT_URL, Tokens oder Release-Tags erforderlich. Falls der Cloudflare-Schutz für die Domain erhalten bleiben soll, benötigt der Publisher stattdessen einen gezielt eingerichteten direkten HTTPS-Zugang zum Origin; auch der BuildKit-Container muss diesen verwenden. Ein erneuter Lauf über dieselbe begrenzte Verbindung behebt HTTP 413 nicht.
+
 ### Neues Release erstellen
 
 ```bash