yaharga

I ran into the same “Download of appfeed failed / Last JSON error: Syntax error” problem on CA 2026.07.21 and did some digging. Posting the diagnostics in case this helps anyone else with a similar ISP/network issue, or if CA can handle this case more gracefully. DNS and general Internet connectivity are fine. ca.unraid.net resolves correctly and other HTTPS sites such as GitHub work normally. The problem is specifically traditional TLS over TCP to ca.unraid.net. A normal request: curl -4 -v https://ca.unraid.net/assets/feed/applicationFeed-lastUpdated.jsonfails during the TLS handshake with either: SSL routines::wrong version numberor: Connection reset by peerI tested the individual Cloudflare destination IPs directly with --resolve, so this is not a DNS-resolution problem. The interesting part is that an OpenSSL debug capture shows why wrong version number occurs. After sending a TLS ClientHello with: SNI = ca.unraid.netthe connection receives plaintext HTTP (HTTP/1.0 200 OK) instead of a TLS record, apparently from ISP filtering/interception infrastructure. Connecting to the same Cloudflare IP without the ca.unraid.net SNI instead receives a genuine TLS response. I also tested from a completely separate mobile ISP. Using the same Cloudflare IP and ca.unraid.net SNI, TLS succeeds normally: CONNECTION ESTABLISHED Protocol version: TLSv1.3 Peer certificate: CN=unraid.net Verification: OKand a normal curl request returns: HTTP/2 200 server: cloudflareSo the problem appears to be ISP/path-specific handling of normal TLS/TCP traffic to ca.unraid.net. HTTP/3 is unaffected. From the affected connection: curl --http3-only https://ca.unraid.net/assets/feed/applicationFeed-lastUpdated.jsonreturns: HTTP/3 200PHP's libcurl on Unraid also supports HTTP/3. I tested the CA endpoint directly using: curl_setopt($ch, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_3ONLY);and got: errno: 0 HTTP: 200 body: {"last_updated_timestamp":...}As a temporary local test, I modified CA's download_url() so that requests whose host is exactly ca.unraid.net use CURL_HTTP_VERSION_3ONLY. Community Applications immediately started working normally again. So in my case the comparison is basically: ca.unraid.net over normal TLS/TCP -> intercepted/fails ca.unraid.net over HTTP/3/QUIC -> HTTP 200 same TLS request over another ISP -> HTTP/2 200 CA forced to HTTP/3 -> Apps worksI have reported the false-positive/interception issue to my ISP. Would it make sense for CA to retry the feed using HTTP/3 when the normal TLS/TCP request fails, assuming the installed libcurl supports it? Alternatively, could there be a fallback feed on a genuinely independent hostname? I noticed the July changes removed the GitHub application-feed fallback, so users behind ISP filtering or other path-specific problems with ca.unraid.net no longer have that independent fallback. I realize this is ultimately an ISP problem, but an automatic HTTP/3 retry/fallback could make CA more resilient to it.