Setup:
- Degoog version: tested on 0.23.0 AND latest 2.0.x - same result on both
- Deployment: Docker (Alpine-based image), self-hosted behind Caddy reverse proxy with TLS
- curl-impersonate: originally v1.2.2, upgraded to v1.5.6 (x86_64-linux-musl) - no change in behavior
- Browser: Zen (Firefox-based, 1.21.6b), extension loaded as temporary add-on
- Transport connected successfully via wss:// through Caddy (Test Connection: OK 200)
Problem:
Google Images engine intermittently returns HTTP 403 (SentinelBreach) or times out,
even when cookies are successfully harvested. Only occasionally returns ~10 results
(vs. 200+ from other engines), never a full result set.
Key finding #1: Session cache not honored
Docs state: "Sessions are cached for 5 hours before the extension may be asked to
refresh them" - implying cached sessions should work even without an active browser
connection. But logs show:
WARN [engine] Google Images failed after 4ms status=network
warn: No browser connected to degoog-4play transport.
at _getSession (/app/data/transports/degoog-org-official-extensions-degoog-fplay/index.js:53:15)
This occurs immediately AFTER a successful cookie harvest in the same session,
suggesting _getSession() requires a live WebSocket connection rather than using
the cached session as documented.
Key finding #2: Background script gets suspended by Firefox
Confirmed via about:debugging - the extension's background script repeatedly goes
from "Wird ausgeführt" (running) to "Angehalten" (suspended) after ~20-30s of
inactivity. This matches the connected/disconnected flapping seen in server logs:
[degoog-4play] browser extension connected
[degoog-4play] got 6 cookies for www.google.com: __Secure-ENID, SEARCH_SAMESITE,
NID, SOCS, __Secure-BUCKET, AEC
[degoog-4play] browser extension disconnected
[degoog-4play] browser extension connected
[degoog-4play] got 0 cookies for example.com:
[degoog-4play] browser extension disconnected
Note "example.com" appears to be a hardcoded placeholder/fallback when the real
session lookup fails - happens intermittently even when the extension was
"connected" moments earlier.
<img width="1886" height="1410" alt="Image" src="https://github.com/user-attachments/assets/60c35d6b-932e-4e78-99ba-8f2a7949a3c5" ### ### ### />
Key finding #3: Even with valid cookies, still 403
In the rare cases where 6 valid google.com cookies ARE attached, Google Images
still returns HTTP 403 (SentinelBreach), ruling out an outdated TLS fingerprint
as the sole cause since curl-impersonate is now on v1.5.6 (May 2026 build).
Troubleshooting already ruled out:
- uBlock Origin: disabled, no change
- Firefox Tracking Protection: disabled, no change
- Reverse proxy / wss:// connectivity: confirmed working (Test Connection 200 OK)
- curl-impersonate binary: confirmed present and updated (v1.5.6 - v2.0.0a5, x86_64-linux-musl)
- Password/WebSocket path config: confirmed correct in both extension and
Degoog settings
Question for maintainer:
Is the 5-hour session cache actually implemented in _getSession(), or does
it currently require a live connection regardless of cache state? And is
"example.com" an intentional fallback placeholder, or a bug where the real
target domain isn't being passed through correctly?
Happy to provide more logs/test builds if helpful.
Setup:
Problem:
Google Images engine intermittently returns HTTP 403 (SentinelBreach) or times out,
even when cookies are successfully harvested. Only occasionally returns ~10 results
(vs. 200+ from other engines), never a full result set.
Key finding #1: Session cache not honored
Docs state: "Sessions are cached for 5 hours before the extension may be asked to
refresh them" - implying cached sessions should work even without an active browser
connection. But logs show:
WARN [engine] Google Images failed after 4ms status=network
warn: No browser connected to degoog-4play transport.
at _getSession (/app/data/transports/degoog-org-official-extensions-degoog-fplay/index.js:53:15)
This occurs immediately AFTER a successful cookie harvest in the same session,
suggesting _getSession() requires a live WebSocket connection rather than using
the cached session as documented.
Key finding #2: Background script gets suspended by Firefox
Confirmed via about:debugging - the extension's background script repeatedly goes
from "Wird ausgeführt" (running) to "Angehalten" (suspended) after ~20-30s of
inactivity. This matches the connected/disconnected flapping seen in server logs:
[degoog-4play] browser extension connected
[degoog-4play] got 6 cookies for www.google.com: __Secure-ENID, SEARCH_SAMESITE,
NID, SOCS, __Secure-BUCKET, AEC
[degoog-4play] browser extension disconnected
[degoog-4play] browser extension connected
[degoog-4play] got 0 cookies for example.com:
[degoog-4play] browser extension disconnected
Note "example.com" appears to be a hardcoded placeholder/fallback when the real
session lookup fails - happens intermittently even when the extension was
"connected" moments earlier.
<img width="1886" height="1410" alt="Image" src="https://github.com/user-attachments/assets/60c35d6b-932e-4e78-99ba-8f2a7949a3c5" ### ### ### />
Key finding #3: Even with valid cookies, still 403
In the rare cases where 6 valid google.com cookies ARE attached, Google Images
still returns HTTP 403 (SentinelBreach), ruling out an outdated TLS fingerprint
as the sole cause since curl-impersonate is now on v1.5.6 (May 2026 build).
Troubleshooting already ruled out:
Degoog settings
Question for maintainer:
Is the 5-hour session cache actually implemented in _getSession(), or does
it currently require a live connection regardless of cache state? And is
"example.com" an intentional fallback placeholder, or a bug where the real
target domain isn't being passed through correctly?
Happy to provide more logs/test builds if helpful.