JournalindeksDockup / feltnote
Note / self-host-whoogle

Sådan selvhoster du Whoogle i 2026: Privatliv, rate limits og proxyindstillinger

Selvhost Whoogle med korrekte porte, persistent storage, HTTPS, secrets, backups og opgraderingskontroller. Lær, hvordan du løser problemer, når upstream blokerer IP-adressen.

En Whoogle-container kan være grøn, selv om det job, brugerne faktisk er interesserede i, er gået i stykker. For Whoogle skyldes den skjulte fejl som regel, at upstream blokerer IP-adressen, eller at proxymiljøvariablerne er forkerte. Denne guide bruger “send søgninger med normale indstillinger og privatlivsindstillinger, verificer resultatlinks, test en upstream-proxy, og udløs den valgte rate limit” som acceptance-test og bygger deploymentet baglæns ud fra dette resultat.

Whoogle har en specifik rolle i stacken: Googles søgeresultater uden annoncer, tracking eller JavaScript på klientsiden. Produktionsspørgsmålet er derfor ikke, om port 5000 svarer én gang, men om state, dependencies og den offentlige adresse fortsat stemmer overens efter en genstart, opdatering og gendannelse.

Definér først, hvad succes betyder for Whoogle

Et nyttigt Whoogle-diagram viser den offentlige route, den private port 5000, state-grænsen og alle understøttende krav. Markér, hvilke pile der transporterer credentials, og hvilke der er almindelig brugertrafik. Det eksterne krav til Whoogle er udgående HTTPS-adgang og en stabil server-IP, som søgeudbyderne accepterer. Test udgående DNS, TLS og udbyderens adfærd uden at publicere endnu en indgående service.

Bevis diagrammet med én reel handling: send søgninger med normale indstillinger og privatlivsindstillinger, verificer resultatlinks, test en upstream-proxy, og udløs den valgte rate limit. Presset kommer sandsynligvis fra blokering hos upstream-søgetjenesten, serverens IP-omdømme, samtidige forespørgsler og proxyens latenstid; overvåg denne sti i stedet for at behandle alle HTTP-forespørgsler ens.

Rout Whoogle uden at foregive, at HTTPS er på plads

Undgå midlertidige og permanente offentlige origins for Whoogle. Publicér i stedet søgeinterfacet via HTTPS med målte rate limits, peg det valgte DNS-navn på platformens route, og proxy kun til port 5000.

Udfør denne handling uden for hosten: send søgninger med normale indstillinger og privatlivsindstillinger, verificer resultatlinks, test en upstream-proxy, og udløs den valgte rate limit. Hvis ingress fejler, dækker guiden til fejlfinding af 502 Bad Gateway fejl i porte og listeners. Hvis Whoogle modtager forespørgslen, men upstream blokerer IP-adressen, eller proxy-miljøvariablerne er forkerte, peger beviserne nu ud over proxyen.

Gør Whoogles opstart reproducerbar

Den første container skal være nem at slette og genskabe. Hold data væk fra det skrivbare lag, bind kun port 5000 dér, hvor proxyen kan nå den, og send konfigurationen ind ved 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

Fastlås image-versionen efter den første test. Læs den tidligste opstartsfejl i stedet for den sidste genstartsmeddelelse, verificer hvert mount med docker inspect, og følg logs, mens du sender søgninger med normale indstillinger og privatlivsindstillinger, verificerer resultatlinks, tester en upstream-proxy og udløser den valgte rate limit. Denne rækkefølge skelner mellem en forkert image-kommando og et problem med en dependency eller tilladelser.

Logs, der besvarer det næste spørgsmål

For Whoogle skal du overvåge en transaktion i stedet for en proces: send søgninger med normale indstillinger og privatlivsindstillinger, verificer resultatlinks, test en upstream-proxy, og udløs den valgte rate limit. Kombinér dens latenstid og fejlrate med blokering hos upstream-søgetjenesten, serverens IP-omdømme, samtidige forespørgsler og proxyens latenstid, så en alert identificerer den komponent, der er begrænsningen.

Opgraderingsprøven skal tage højde for, at markup hos upstream og Whoogle-releases kan ødelægge parsing, uden at containeren bliver unhealthy. Gendan, migrér, og kør transaktionen før udskiftning i produktion. Hvis upstream blokerer IP-adressen, eller proxy-miljøvariablerne er forkerte, skal du ikke slette data for at få en grøn opstart; sammenlign version, variabler, mounts og dependency-reachability i den rækkefølge.

Gør Whoogles smoke-test til et release-tjek

Opret en lille, midlertidig Whoogle-fixture, og behold den til hvert release. Fixturen skal afprøve det reelle workflow: send søgninger med normale indstillinger og privatlivsindstillinger, verificer resultatlinks, test en upstream-proxy, og udløs den valgte rate limit. Notér image-digest, eksternt hostname, dependency-adresse og det forventede resultat, så en senere operatør kan gentage testen uden at skulle fortolke denne guide.

Kør fixturen tre gange. Brug først det friske deployment. Udskift derefter containeren uden at ændre persistent state. Gendan til sidst backuppen i et tomt miljø. Den tredje kørsel består kun, når konfiguration og præferencer kommer tilbage, og et fast sæt forespørgsler stadig giver brugbare resultatlinks. Under hver kørsel skal du registrere latenstid og ressourceforbrug omkring blokering hos upstream-søgetjenesten, serverens IP-omdømme, samtidige forespørgsler og proxyens latenstid; det bliver baseline for alerts i stedet for en vilkårlig CPU-procent.

Test til sidst den negative sti bevidst: blokér midlertidigt den teststi, der bruges til udgående HTTPS-adgang og en stabil server-IP, som søgeudbyderne accepterer. Bekræft, at Whoogle fejler synligt uden at ødelægge state, genskab den korrekte tilstand, og gentag den vellykkede transaktion. En release-registrering med disse fire resultater er stærkere dokumentation end screenshots af et dashboard eller et enkeltstående curl-svar.

Find alle persistente bytes i Whoogle

Lav en fortegnelse over alle persistente artefakter: konfiguration og eventuelle brugerpræferencer, der er gemt på disken. Mount /config før bootstrap, skriv ufarlige eksempeldata, og udskift containeren for at bevise, at stien faktisk er persistent. Medtag konfiguration, der ændrer, hvordan gemte data fortolkes, ikke kun den største mappe.

Fastlæg retention, kopiér backups væk fra hosten, og kør en clean-room restore. Whoogle-øvelsen er færdig, når konfiguration og præferencer kommer tilbage, og et fast sæt forespørgsler stadig giver brugbare resultatlinks. Hvis snapshots indgår i planen, kan du bruge vejledningen om PITR versus snapshots til at dokumentere, hvad de enkelte mekanismer kan gendanne.

Beskyt den værdifulde del af Whoogle

Et sikkert Whoogle-deployment begynder med at fjerne privilegier. Undgå at køre en åben offentlig proxy uden abuse controls; beskyt i stedet enhver offentlig instans med authentication eller rate controls, og hold proxy-credentials ude af imaget.

Udskift straks eksempelværdien for WHOOGLE_CONFIG_PASSWORD, opbevar den uden for imaget, og rotér den som en administrator-credential, hvis den bliver eksponeret. Begræns administrative routes, brug privat DNS til dependencies, og gennemgå hvert bind mount. Når logs sendes til et centralt system, skal secrets og privat indhold filtreres, før de forlader serveren.

Hvad Dockup bør automatisere for Whoogle

Dockup fjerner manuelt reverse-proxy- og lifecycle-arbejde omkring Whoogle. Servicen får en stabil HTTPS-route til port 5000, injiceret konfiguration og persistent storage under udskiftninger. En tilknyttet kundeserver følger samme model som Dockup-hostet compute.

Efter launch skal du opfylde applikationskontrakten: publicér søgeinterfacet via HTTPS med målte rate limits, tillad og verificér udgående HTTPS-adgang samt en stabil server-IP, som søgeudbyderne accepterer, og kør dette proof: send søgninger med normale indstillinger og privatlivsindstillinger, verificér resultatlinks, test en upstream-proxy, og udløs den valgte rate limit. Det gør one-click-oplevelsen nyttig uden at udviske de detaljer, der gør Whoogle gendannelig og sikker.

Ofte stillede spørgsmål

Hvad har Whoogle brug for i et produktionsdeployment?

Rout Whoogle-containeren på port 5000 gennem én HTTPS-origin. Det eksterne leveringskrav er udgående HTTPS-adgang og en stabil server-IP, som søgeudbyderne accepterer. Kald ikke Whoogle klar, før du kan sende søgninger med normale indstillinger og privatlivsindstillinger, verificere resultatlinks, teste en upstream-proxy og udløse den valgte rate limit.

Hvilke Whoogle-data hører til i en backup?

Persistér /config, og medtag konfiguration samt eventuelle brugerpræferencer, der er gemt på disken, i det samme recovery-manifest. En clean Whoogle-restore består kun, når konfiguration og præferencer kommer tilbage, og et fast sæt forespørgsler stadig giver brugbare resultatlinks.

Kræver Whoogle HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige Whoogle-origin, og behold port 5000 på den interne route. Anvend Whoogle-indstillingen korrekt: publicér søgeinterfacet via HTTPS med målte rate limits. For Whoogle beskytter HTTPS credentials eller brugerindhold under transport og sikrer, at origin-følsom klientadfærd forbliver konsistent.

Hvordan bør en Whoogle-opgradering testes?

Gendan den aktuelle Whoogle-state i et isoleret deployment, anvend kandidatversionen, og gentag dens acceptance-transaktion. Vær særligt opmærksom, fordi markup hos upstream og Whoogle-releases kan ødelægge parsing, uden at containeren bliver unhealthy. Behold det tidligere Whoogle-image, indtil grænsen for datamigrering og rollback er forstået.