Whoogle zelf hosten in 2026: privacy, rate limits en proxy-instellingen

Een Whoogle-container kan groen zijn terwijl de functionaliteit die gebruikers belangrijk vinden niet werkt. Bij Whoogle is die verborgen fout meestal dat de upstream het IP-adres blokkeert of dat de proxy-omgevingsvariabelen niet kloppen. In deze handleiding geldt de volgende controle als acceptatietest: “voer zoekopdrachten uit met normale en privacy-instellingen, controleer de links in de resultaten, test een upstream-proxy en activeer de gekozen rate limit”. De deployment wordt vanuit dat resultaat terug opgebouwd.

Whoogle heeft een specifieke rol in de stack: Google-zoekresultaten zonder advertenties, tracking of JavaScript aan de clientzijde. De vraag voor productie is daarom niet of poort 5000 één keer antwoord geeft, maar of state, dependencies en het publieke adres na een restart, update en restore nog steeds op elkaar zijn afgestemd.

Definieer eerst wanneer Whoogle geslaagd is

Een bruikbaar Whoogle-diagram toont de publieke route, private poort 5000, stategrens en alle ondersteunende vereisten. Markeer welke pijlen credentials bevatten en welke gewoon gebruikersverkeer vervoeren. De externe vereiste voor Whoogle is uitgaande HTTPS-toegang en een stabiel server-IP-adres dat door zoekproviders wordt geaccepteerd. Test uitgaande DNS, TLS en het gedrag van de provider zonder nog een inkomende service te publiceren.

Bewijs het diagram met één echte actie: voer zoekopdrachten uit met normale en privacy-instellingen, controleer de links in de resultaten, test een upstream-proxy en activeer de gekozen rate limit. De meeste druk komt waarschijnlijk van blokkades door upstream-zoekproviders, de reputatie van het server-IP-adres, gelijktijdige queries en proxy-latency; monitor dat pad in plaats van alle HTTP-requests als gelijkwaardig te behandelen.

Routeer Whoogle zonder HTTPS verkeerd voor te stellen

Vermijd tijdelijke en permanente publieke origins voor Whoogle. Publiceer de zoekinterface in plaats daarvan via HTTPS met gemeten rate limits, laat de gekozen DNS-naam naar de platformroute wijzen en proxy alleen naar poort 5000.

Voer deze actie uit vanaf buiten de host: voer zoekopdrachten uit met normale en privacy-instellingen, controleer de links in de resultaten, test een upstream-proxy en activeer de gekozen rate limit. Als ingress niet werkt, behandelt de handleiding voor het oplossen van 502 Bad Gateway fouten met poorten en listeners. Als Whoogle het request wel ontvangt, maar de upstream het IP-adres blokkeert of de proxy-omgevingsvariabelen niet kloppen, wijst het bewijs nu op een probleem buiten de proxy.

Maak de startup van Whoogle reproduceerbaar

De eerste container moet eenvoudig te verwijderen en opnieuw aan te maken zijn. Houd data buiten de writable layer, bind poort 5000 alleen op plaatsen waar de proxy erbij kan en geef configuratie door tijdens runtime.

docker run -d \
  --name whoogle \
  --restart unless-stopped \
  -p 127.0.0.1:5000:5000 \
  -v whoogle-data:/config \
  -e WHOOGLE_CONFIG_PASSWORD=replace-with-a-long-random-value \
  benbusby/whoogle-search:latest

Pin de image na de eerste test. Lees de eerste startupfout in plaats van het laatste restartbericht, controleer elke mount met docker inspect en volg de logs terwijl je zoekopdrachten uitvoert met normale en privacy-instellingen, de links in de resultaten controleert, een upstream-proxy test en de gekozen rate limit activeert. Met die volgorde maak je onderscheid tussen een verkeerd imagecommando en een probleem met dependencies of permissies.

Logs die de volgende vraag beantwoorden

Monitor bij Whoogle een transactie in plaats van een proces: voer zoekopdrachten uit met normale en privacy-instellingen, controleer de links in de resultaten, test een upstream-proxy en activeer de gekozen rate limit. Combineer de latency en error rate met blokkades door upstream-zoekproviders, de reputatie van het server-IP-adres, gelijktijdige queries en proxy-latency, zodat een alert duidelijk maakt welk component de beperking veroorzaakt.

De upgrade-repetitie moet rekening houden met het feit dat markup van de upstream en Whoogle-releases parsing kunnen breken zonder dat de container ongezond wordt. Voer een restore en migratie uit en run de transactie vóór je de productieomgeving vervangt. Als de upstream het IP-adres blokkeert of de proxy-omgevingsvariabelen niet kloppen, wis dan geen data om de startup groen te maken; vergelijk achtereenvolgens de versie, variabelen, mounts en bereikbaarheid van dependencies.

Maak van de Whoogle-smoketest een releasecontrole

Maak een kleine, wegwerpbare Whoogle-fixture en bewaar die voor elke release. De fixture moet de echte workflow uitvoeren: zoekopdrachten indienen met normale en privacy-instellingen, de links in de resultaten controleren, een upstream-proxy testen en de gekozen rate limit activeren. Noteer de image digest, externe hostname, het adres van de dependency en het verwachte resultaat, zodat een volgende operator de test kan herhalen zonder deze handleiding te hoeven interpreteren.

Voer de fixture drie keer uit. Gebruik eerst de verse deployment. Vervang daarna de container zonder de persistente state aan te raken. Herstel ten slotte de back-up in een lege omgeving. De derde run slaagt alleen wanneer de configuratie en voorkeuren terug zijn en een vaste set queries nog steeds bruikbare links in de resultaten oplevert. Leg tijdens elke run de latency en het resourcegebruik vast rond blokkades door upstream-zoekproviders, de reputatie van het server-IP-adres, gelijktijdige queries en proxy-latency; dit wordt de basis voor alerts in plaats van een willekeurig CPU-percentage.

Test ten slotte bewust het negatieve pad: blokkeer tijdelijk het testpad dat wordt gebruikt voor uitgaande HTTPS-toegang en een stabiel server-IP-adres dat door zoekproviders wordt geaccepteerd. Controleer of Whoogle zichtbaar faalt zonder de state te beschadigen, herstel de juiste conditie en herhaal de geslaagde transactie. Een releaserecord met die vier uitkomsten levert sterker bewijs dan screenshots van een dashboard of een eenmalige curl-respons.

Vind elke persistente byte in Whoogle

Inventariseer elk persistent artefact: configuratie en eventuele gebruikersvoorkeuren die op schijf zijn opgeslagen. Mount /config vóór de bootstrap, schrijf onschadelijke voorbeelddata en vervang de container om te bewijzen dat dat pad daadwerkelijk persistent is. Neem ook configuratie op die bepaalt hoe opgeslagen data wordt geïnterpreteerd, niet alleen de grootste directory.

Stel de bewaartermijn in, kopieer back-ups naar een andere host en voer een clean-room restore uit. De Whoogle-oefening is voltooid wanneer de configuratie en voorkeuren terug zijn en een vaste set queries nog steeds bruikbare links in de resultaten oplevert. Als snapshots onderdeel zijn van het plan, gebruik dan de richtlijnen voor PITR versus snapshots om vast te leggen wat elk mechanisme kan herstellen.

Bescherm het waardevolle deel van Whoogle

Een veilige Whoogle-deployment begint met het wegnemen van bevoegdheden. Vermijd een open publieke proxy zonder maatregelen tegen misbruik; bescherm een publieke instance in plaats daarvan met authenticatie of rate controls en houd proxy-credentials buiten de image.

Vervang de voorbeeldwaarde van WHOOGLE_CONFIG_PASSWORD onmiddellijk, sla deze buiten de image op en roteer het wachtwoord zoals een administratorcredential als het uitlekt. Beperk administratieve routes, gebruik private DNS voor dependencies en controleer elke bind mount. Wanneer logs centraal worden verzonden, filter je secrets en privé-inhoud voordat ze de server verlaten.

Wat Dockup voor Whoogle moet automatiseren

Dockup neemt handmatig reverse-proxy- en lifecyclewerk rond Whoogle uit handen. De service krijgt tijdens vervangingen een stabiele HTTPS-route naar 5000, geïnjecteerde configuratie en persistente opslag. Een gekoppelde klantserver volgt hetzelfde model als door Dockup gehoste compute.

Voldoe na de launch aan het applicatiecontract: publiceer de zoekinterface via HTTPS met gemeten rate limits, sta uitgaande HTTPS-toegang en een stabiel server-IP-adres dat door zoekproviders wordt geaccepteerd toe en verifieer dit, en voer deze controle uit: dien zoekopdrachten in met normale en privacy-instellingen, controleer de links in de resultaten, test een upstream-proxy en activeer de gekozen rate limit. Zo blijft de one-click-ervaring bruikbaar zonder de details weg te abstraheren die Whoogle herstelbaar en veilig maken.

Veelgestelde vragen

Wat heeft Whoogle nodig voor een productie-deployment?

Routeer de Whoogle-container via poort 5000 door één HTTPS-origin. De externe leveringsvereiste is uitgaande HTTPS-toegang en een stabiel server-IP-adres dat door zoekproviders wordt geaccepteerd. Noem Whoogle pas klaar als je zoekopdrachten kunt indienen met normale en privacy-instellingen, de links in de resultaten kunt controleren, een upstream-proxy kunt testen en de gekozen rate limit kunt activeren.

Welke Whoogle-data hoort in een back-up?

Maak een back-up van /config en neem configuratie en eventuele gebruikersvoorkeuren die op schijf zijn opgeslagen op in hetzelfde recovery-manifest. Een clean Whoogle-restore slaagt alleen wanneer de configuratie en voorkeuren terug zijn en een vaste set queries nog steeds bruikbare links in de resultaten oplevert.

Heeft Whoogle HTTPS nodig achter een reverse proxy?

Gebruik HTTPS voor de publieke Whoogle-origin en houd poort 5000 op de interne route. Pas de Whoogle-instelling correct toe: publiceer de zoekinterface via HTTPS met gemeten rate limits. Bij Whoogle beschermt HTTPS credentials of gebruikersinhoud tijdens het transport en zorgt het ervoor dat origin-gevoelig gedrag van de client consistent blijft.

Hoe test je een Whoogle-upgrade?

Herstel de huidige Whoogle-state in een geïsoleerde deployment, pas de kandidaatversie toe en herhaal de acceptatietransactie. Let hier extra op, omdat markup van de upstream en Whoogle-releases parsing kunnen breken zonder dat de container ongezond wordt. Bewaar de vorige Whoogle-image totdat de grenzen voor datamigratie en rollback duidelijk zijn.