Så självhostar du Whoogle 2026: integritet, rate limits och proxyinställningar

En Whoogle-container kan vara grön samtidigt som det användarna faktiskt behöver är trasigt. För Whoogle beror det dolda felet oftast på att upstream blockerar IP-adressen eller att proxyvariablerna är felaktiga. Den här guiden utgår från följande acceptanstest: ”skicka sökningar med normala integritetsinställningar och privacy-inställningar, verifiera resultatlänkar, testa en upstream-proxy och utlös den valda rate limiten” och bygger distributionen bakifrån utifrån det resultatet.

Whoogle har en specifik roll i stacken: Googles sökresultat utan annonser, spårning eller JavaScript på klientsidan. Produktionsfrågan är därför inte om port 5000 svarar en gång, utan om state, beroenden och den publika adressen fortsätter att stämma överens efter en omstart, uppdatering och återställning.

Definiera först vad som räknas som lyckat för Whoogle

Ett användbart Whoogle-diagram visar den publika routen, den privata porten 5000, state-gränsen och alla stödkrav. Markera vilka pilar som transporterar autentiseringsuppgifter och vilka som är vanlig användartrafik. Det externa kravet för Whoogle är utgående HTTPS-åtkomst och en stabil server-IP som sökleverantörer accepterar. Testa utgående DNS, TLS och leverantörens beteende utan att publicera ytterligare en inkommande tjänst.

Bevisa diagrammet med en verklig åtgärd: skicka sökningar med normala integritetsinställningar och privacy-inställningar, verifiera resultatlänkar, testa en upstream-proxy och utlös den valda rate limiten. Den troliga belastningen kommer från blockering hos upstream-sökningen, serverns IP-rykte, samtidiga frågor och proxyfördröjning; övervaka den sökvägen i stället för att behandla alla HTTP-förfrågningar som likvärdiga.

Routa Whoogle utan att ge en felaktig bild av HTTPS

Undvik tillfälliga och permanenta publika origins för Whoogle. Publicera i stället sökgränssnittet via HTTPS med uppmätta rate limits, peka det valda DNS-namnet mot plattformsrouten och proxya endast till port 5000.

Testa åtgärden utifrån hosten: skicka sökningar med normala integritetsinställningar och privacy-inställningar, verifiera resultatlänkar, testa en upstream-proxy och utlös den valda rate limiten. Om ingress misslyckas beskriver felsökningsguiden för 502 Bad Gateway vanliga port- och listener-fel. Om Whoogle tar emot förfrågan men upstream blockerar IP-adressen eller proxyvariablerna är felaktiga, pekar bevisen nu bortom proxyn.

Gör Whoogles uppstart reproducerbar

Den första containern ska vara enkel att ta bort och skapa på nytt. Håll data borta från det skrivbara lagret, bind port 5000 endast där proxyn kan nå den och skicka konfigurationen vid körning.

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

Lås image-versionen efter det första testet. Läs det tidigaste uppstartsfelet i stället för det sista omstartsmeddelandet, verifiera varje mount med docker inspect och följ loggarna medan du skickar sökningar med normala integritetsinställningar och privacy-inställningar, verifierar resultatlänkar, testar en upstream-proxy och utlöser den valda rate limiten. Den sekvensen skiljer ett felaktigt image-kommando från ett problem med beroenden eller behörigheter.

Loggar som besvarar nästa fråga

För Whoogle ska du övervaka en transaktion i stället för en process: skicka sökningar med normala integritetsinställningar och privacy-inställningar, verifiera resultatlänkar, testa en upstream-proxy och utlös den valda rate limiten. Kombinera latens och felfrekvens med blockering hos upstream-sökningen, serverns IP-rykte, samtidiga frågor och proxyfördröjning så att en alert identifierar den komponent som är begränsande.

Repetitionen inför en uppgradering måste täcka att markup hos upstream och Whoogle-releaser kan göra parsningen felaktig utan att containern blir ohälsosam. Återställ, migrera och kör transaktionen före produktionsbytet. Om upstream blockerar IP-adressen eller proxyvariablerna är felaktiga ska du inte radera data för att få en grön uppstart; jämför version, variabler, mounts och åtkomlighet till beroenden i den ordningen.

Gör Whoogles smoke test till en releasekontroll

Skapa en liten, temporär Whoogle-fixture och behåll den för varje release. Fixturen ska testa det verkliga arbetsflödet: skicka sökningar med normala integritetsinställningar och privacy-inställningar, verifiera resultatlänkar, testa en upstream-proxy och utlös den valda rate limiten. Dokumentera image digest, externt hostname, beroendeadress och det förväntade resultatet så att en senare operatör kan upprepa testet utan att behöva tolka den här guiden.

Kör fixturen tre gånger. Använd först den nya distributionen. Byt sedan ut containern utan att röra beständig state. Återställ slutligen säkerhetskopian till en tom miljö. Den tredje körningen godkänns endast när konfiguration och inställningar återkommer och en fast uppsättning frågor fortfarande ger användbara resultatlänkar. Samla under varje körning in latens och resursanvändning kring blockering hos upstream-sökningen, serverns IP-rykte, samtidiga frågor och proxyfördröjning; detta blir baslinjen för alerts i stället för en godtycklig CPU-procent.

Testa slutligen den negativa vägen med avsikt: neka tillfälligt den testsökväg som används för utgående HTTPS-åtkomst och en stabil server-IP som sökleverantörer accepterar. Bekräfta att Whoogle misslyckas synligt utan att state skadas, återställ det korrekta villkoret och upprepa den lyckade transaktionen. En releasepost med dessa fyra resultat är starkare bevis än skärmbilder av en dashboard eller ett engångssvar från curl.

Hitta varje beständig byte i Whoogle

Inventera alla beständiga artefakter: konfiguration och eventuella användarinställningar som lagras på disk. Moun­ta /config före bootstrap, skriv ofarliga exempeldata och byt ut containern för att bevisa att sökvägen faktiskt är beständig. Inkludera konfiguration som ändrar hur lagrade data tolkas, inte bara den största katalogen.

Definiera retention, kopiera säkerhetskopior utanför hosten och genomför en återställning i en ren miljö. Whoogle-övningen är klar när konfiguration och inställningar återkommer och en fast uppsättning frågor fortfarande ger användbara resultatlänkar. Om snapshots ingår i planen kan du använda vägledningen om PITR kontra snapshots för att dokumentera vad varje mekanism kan återställa.

Skydda det värdefulla i Whoogle

En säker Whoogle-distribution börjar med att ta bort behörigheter. Undvik att köra en öppen publik proxy utan skydd mot missbruk; skydda i stället alla publika instanser med autentisering eller rate controls och lägg inte proxyuppgifter i imagen.

Byt ut exempelvärdet för WHOOGLE_CONFIG_PASSWORD omedelbart, lagra det utanför imagen och rotera det som en administratörsuppgift om det exponeras. Begränsa administrativa routes, använd privat DNS för beroenden och granska varje bind mount. När loggar skickas centralt ska du filtrera bort hemligheter och privat innehåll innan de lämnar servern.

Vad Dockup bör automatisera för Whoogle

Dockup tar bort manuellt arbete med reverse proxy och livscykelhantering kring Whoogle. Tjänsten får en stabil HTTPS-route till 5000, injicerad konfiguration och beständig lagring vid byten. En ansluten kundserver följer samma modell som compute-hosting hos Dockup.

Efter lanseringen ska applikationskontraktet uppfyllas: publicera sökgränssnittet via HTTPS med uppmätta rate limits, tillåt och verifiera utgående HTTPS-åtkomst och en stabil server-IP som sökleverantörer accepterar och genomför detta bevis: skicka sökningar med normala integritetsinställningar och privacy-inställningar, verifiera resultatlänkar, testa en upstream-proxy och utlös den valda rate limiten. På så sätt förblir one-click-upplevelsen användbar utan att förenkla bort detaljerna som gör Whoogle återställningsbart och säkert.

Vanliga frågor

Vad behöver Whoogle för en produktionsdistribution?

Routa Whoogle-containern på port 5000 genom ett enda HTTPS-origin. Det externa leveranskravet är utgående HTTPS-åtkomst och en stabil server-IP som sökleverantörer accepterar. Anse inte Whoogle vara redo förrän du kan skicka sökningar med normala integritetsinställningar och privacy-inställningar, verifiera resultatlänkar, testa en upstream-proxy och utlösa den valda rate limiten.

Vilka Whoogle-data ska ingå i en säkerhetskopia?

Beständig lagring för /config och inkludera konfiguration samt eventuella användarinställningar som lagras på disk i samma återställningsmanifest. En ren återställning av Whoogle är godkänd först när konfiguration och inställningar återkommer och en fast uppsättning frågor fortfarande ger användbara resultatlänkar.

Kräver Whoogle HTTPS bakom en reverse proxy?

Använd HTTPS för den publika Whoogle-originen och behåll port 5000 på den interna routen. Tillämpa Whoogle-inställningen korrekt: publicera sökgränssnittet via HTTPS med uppmätta rate limits. För Whoogle skyddar HTTPS autentiseringsuppgifter eller användarinnehåll under överföring och gör klientbeteende som är känsligt för originen konsekvent.

Hur bör en Whoogle-uppgradering testas?

Återställ aktuell Whoogle-state till en isolerad distribution, tillämpa kandidatversionen och upprepa acceptanstransaktionen. Var särskilt uppmärksam eftersom markup hos upstream och Whoogle-releaser kan göra parsningen felaktig utan att containern blir ohälsosam. Behåll den tidigare Whoogle-imagen tills gränserna för datamigrering och rollback är förstådda.