Avatarbilder werden hinter Proxy nicht angezeigt

User Talk Base design
1

Wir testen gerade SeaTable als potentielle Lösung für verschiedene Aufgaben in der Cloud. Die Avatar-Bilder werden hinter unserem Proxy nicht angezeigt. Diese werden ja von einer dedizierten Domain geladen. Obwohl diese Domain in der Whitelist hinzugefügt wurde, bleibt der Fehler bestehen.

net::ERR_TUNNEL_CONNECTION_FAILED

Hat hierfür jemand einen Lösungsansatz?

Im voraus Danke für die Hilfe und viele Grüße

Harald

2

Hallo Harald,
kannst du ein bischen mehr informationen liefern?

  • welche Version
  • Welchen Proxy
  • welche Zertifikate
  • welche URLs werden aufgerufen
  • was ist die vollständige Fehlermeldung
  • …
3

wir arbeiten auf cloud.seatable.io. Da wird keine Versionsnummer angegeben.

Als Proxy kommt Squid zum Einsatz.

Die Avatare werden von https://sos-de-fra-1.exo.io/seatable-io-avatar/… geladen.

Fehlermeldung im Browser/Network:

curl 'https://sos-de-fra-1.exo.io/seatable-io-avatar/avatars/0/8/2d32d9748145dacb8efdc9163735c7/resized/256/19bba34eff7f6d4f638038502d5bf247_ZcP4TXk.png' \
  -H 'sec-ch-ua-platform: "Windows"' \
  -H 'Referer;' \
  -H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36' \
  -H 'sec-ch-ua: "Google Chrome";v="147", "Not.A/Brand";v="8", "Chromium";v="147"' \
  -H 'sec-ch-ua-mobile: ?0'

Fehlermeldung im Proxy (Anfrage wird weggeblockt):

[23/Apr/2026:14:48:33 +0200] "CONNECT sos-de-fra-1.exo.io:443 HTTP/1.1" 309 331 TCP_DENIED:HIER_NONE
 - - [23/Apr/2026:14:48:33 +0200] "CONNECT sos-de-fra-1.exo.io:443 HTTP/1.1" 309 331 TCP_DENIED:HIER_NONE

Hilft das weiter?

Viele Grüße
Harald

4

Hallo Harald,

das ist ein Squid-Konfigurationsthema bei euch, kein SeaTable-Problem.

Die Zeile TCP_DENIED:HIER_NONE im Proxy-Log bedeutet, dass Squid die Verbindung durch eine eigene ACL ablehnt. Die Anfrage erreicht den S3 Speicher bei Exoscale also gar nicht erst.

Hintergrund: Avatare (und einige andere statische Inhalte) liefert cloud.seatable.io nicht selbst aus, sondern aus unserem Object Storage bei Exoscale unter sos-de-fra-1.exo.io. Diese Domain muss in eurer Squid-Whitelist zusätzlich zu *.seatable.io freigegeben werden.

Da der Browser über HTTPS per CONNECT … :443 tunnelt, braucht es eine dstdomain-Freigabe, z. B.:

acl seatable_storage dstdomain sos-de-fra-1.exo.io
http_access allow seatable_storage

Nach dem Reload von Squid sollten die Avatare wieder laden.

Viele Grüße
Christoph