RapiD

Hallo zusammen, ich möchte ein Problem mit Community Applications dokumentieren, das bei mir vermutlich mit dem Routing meiner Deutschen-Telekom-DSL-Verbindung zu ca.unraid.net zusammenhing. Vielleicht hilft das anderen Nutzern, die dieselbe Fehlermeldung sehen. FehlerbildBeim Öffnen des Tabs Apps erschien folgende Meldung: Dabei war zunächst auffällig: Unraid hatte grundsätzlich Internetzugang. DNS-Auflösung funktionierte. GitHub war erreichbar. Docker-Updates wurden weiterhin erkannt und konnten installiert werden. Ich hatte vorher keine bewusste Änderung an Unraid oder meinem Netzwerk vorgenommen. Grundlegende TestsDie Internetverbindung funktionierte: ping -c 4 1.1.1.1 ping -c 4 raw.githubusercontent.comBeide Ziele waren ohne Paketverlust erreichbar. Auch HTTPS zu GitHub funktionierte: curl -I -L --max-time 20 https://raw.githubusercontent.com curl -I -L --max-time 20 https://github.comBeide Tests lieferten HTTP 200. Das installierte Community-Applications-Plugin war aktuell und verwendete das offizielle Repository: Version: 2026.07.21 Repository: unraid/community.applicationsDie tatsächlich verwendeten Feed-Adressen waren: https://ca.unraid.net/assets/feed/applicationFeed.json https://ca.unraid.net/cdn/feed/applicationFeed.jsonDie eigentliche UrsacheDer Feed war grundsätzlich erreichbar, wurde über meinen normalen DSL-Anschluss aber extrem langsam übertragen. Testbefehl: curl -4 -L --max-time 30 \ -o /dev/null \ -w "HTTP: %{http_code}\nTempo: %{speed_download} Bytes/s\nIP: %{remote_ip}\n" \ https://ca.unraid.net/cdn/feed/applicationFeed.jsonOhne VPN lag die Geschwindigkeit nur bei ungefähr: HTTP: 200 Tempo: 8.000–22.000 Bytes/sDer Feed ist rund 17 MB groß. Dadurch dauerte der Download viel zu lange. Community Applications brach offenbar ab, bevor die vollständige JSON-Datei geladen war. Die unvollständige Datei führte anschließend vermutlich zu: Last JSON error recorded: Syntax errorAuch auf einem Windows-PC im selben Netzwerk lud dieselbe Feed-Datei sehr langsam und benötigte ungefähr zwei Minuten. Vergleich über andere VerbindungenZum Gegencheck habe ich dieselbe Datei über andere Verbindungen geöffnet: Normaler Telekom-DSL-Weg: ca. 8–22 KB/s Mobilfunk: unter 10 Sekunden VPN: ca. 8 SekundenDamit war klar, dass das Problem sehr wahrscheinlich nicht direkt an Unraid, Community Applications, Docker oder DNS lag. NetzwerkumgebungMein Aufbau: Deutsche Telekom DSL FRITZ!Box nur als DSL-Modem UniFi Cloud Gateway Ultra für PPPoE, Routing, NAT und Firewall MTU erfolgreich mit 1492 getestet IPv6 auf Unraid deaktiviert Auch ein testweises Deaktivieren des UniFi-Bedrohungsschutzes brachte keine ausreichende Verbesserung. WorkaroundIch habe auf der UniFi Cloud Gateway Ultra ein richtlinienbasiertes Routing eingerichtet: Zieldomain: ca.unraid.net Route: über einen VPN-ClientEs wird also ausschließlich der Verkehr zu ca.unraid.net über den VPN-Tunnel geleitet. Der restliche Datenverkehr, darunter Docker, Reverse Proxy, öffentliche Dienste und normaler Internetzugriff, läuft weiterhin über den normalen DSL-Anschluss. Danach ergab derselbe Test: HTTP: 200 Tempo: 7.845.632 Bytes/s Downloadzeit: ungefähr 2 SekundenCommunity Applications funktionierte anschließend sofort wieder. FazitIn meinem Fall deutet alles auf einen sehr langsamen Routing- oder Peering-Weg zwischen meinem Deutsche-Telekom-DSL-Anschluss und der Cloudflare-/Unraid-Infrastruktur hinter ca.unraid.net hin. Ich kann nicht sicher sagen, ob: generell Deutsche-Telekom-Kunden betroffen sind, nur bestimmte Anschlussbereiche oder IP-Bereiche betroffen sind, oder ob es sich um ein vorübergehendes Routingproblem handelt. Der Unterschied zwischen normalem Telekom-Routing und VPN war bei mir jedoch sehr deutlich. Bevor Community Applications neu installiert oder DNS komplett umgebaut wird, würde ich daher empfehlen, zunächst diesen Test auszuführen: curl -4 -L --max-time 30 \ -o /dev/null \ -w "HTTP: %{http_code}\nTempo: %{speed_download} Bytes/s\nIP: %{remote_ip}\n" \ https://ca.unraid.net/cdn/feed/applicationFeed.jsonAnschließend kann man dieselbe Adresse testweise über Mobilfunk oder VPN öffnen. Vielleicht hilft dieser Hinweis anderen Nutzern mit derselben Fehlermeldung.