vh
0f748ea54e
The ana-docker instance was returning zero results for every query while reporting healthy — 4.5 months stale (2026.4.17 against a current 2026.9.3), its engine scrapers rotted against sites that had changed. /healthz proves the web app answers and says nothing about whether search works, so seven days of green sat on top of a search box that found nothing. Moved to nh3-docker rather than updated in place, because the colo egress is the other half of the problem: 38.120.12.42 is a datacenter address that DuckDuckGo and Startpage CAPTCHA, while nh3-docker egresses residentially at 70.230.226.88. Same reasoning as the fleet's residential proxy for yt-dlp, applied at the source instead of around it. Config corrected along the way: base_url said searxng.pfi.local, a name retired on 2026-08-19, while the environment said something else — the env won so nothing broke and the file quietly lied. The karmasearch.videos removal key never matched, because the engine's real name has a space. scripts/searxng-health.sh asserts results > 0 across three unrelated queries. That is the check that would have caught this, and the only kind that can: the mechanism was healthy throughout. services/searxng-mcp exposes it as `web_search` at user scope, so every Claude Code session has it. Zero results raise rather than returning an empty list — an empty list is indistinguishable from a broken aggregator, which is precisely how this hid. Old instance stopped and removed; DNS alias repointed to searxng.nh3.internal.
65 lines
2.4 KiB
YAML
65 lines
2.4 KiB
YAML
services:
|
|
searxng:
|
|
# ⚠ `:latest` means "latest AT PULL TIME", and nothing re-pulls on its own.
|
|
# On 2026-09-03 this instance was found running 2026.4.17 — 4.5 months old —
|
|
# while reporting `healthy` and returning ZERO results for every query,
|
|
# because SearXNG engine scrapers rot as upstream sites change their markup
|
|
# and the project ships near-daily releases to keep up. `docker compose pull
|
|
# && up -d` is the update; scripts/searxng-health.sh is what tells you it is
|
|
# needed, because /healthz cannot.
|
|
image: searxng/searxng:latest
|
|
container_name: searxng
|
|
restart: unless-stopped
|
|
ports:
|
|
- 9996:8080
|
|
volumes:
|
|
- /opt/docker/conf/searxng/searxng-settings.yml:/etc/searxng/settings.yml:ro
|
|
environment:
|
|
- SEARXNG_SECRET=${SEARXNG_SECRET}
|
|
- BASE_URL=http://10.100.50.40:9996/
|
|
- INSTANCE_NAME=SearXNG
|
|
deploy:
|
|
resources:
|
|
limits:
|
|
memory: 512M
|
|
cpus: "1.0"
|
|
reservations:
|
|
memory: 128M
|
|
# ⚠ `--tries=1` MUST keep its `=1`. Written as two argv entries
|
|
# (`- --tries` / `- --spider`) wget consumes `--spider` as the VALUE of
|
|
# `--tries`, spider mode never engages, and every probe DOWNLOADS the
|
|
# response to a file. On the ana-docker instance that left 295,287
|
|
# `healthz.N` files in the container's writable layer, one per probe since
|
|
# April; wget scanning them to pick the next free name is what blew the 10s
|
|
# timeout and made the dashboard card flap. Self-worsening — each probe made
|
|
# the next slower. Watch for `docker exec searxng ls | wc -l` climbing.
|
|
#
|
|
# ⚠ AND KNOW WHAT THIS PROBE DOES NOT TELL YOU: /healthz proves the web app
|
|
# answers. It says nothing about whether any engine returns a result. Seven
|
|
# days of `healthy` sat on top of a search box that found nothing.
|
|
healthcheck:
|
|
test:
|
|
- CMD
|
|
- wget
|
|
- --no-verbose
|
|
- --tries=1
|
|
- --spider
|
|
- http://localhost:8080/healthz
|
|
interval: 30s
|
|
timeout: 10s
|
|
retries: 3
|
|
start_period: 15s
|
|
networks:
|
|
- tnet
|
|
labels:
|
|
- homepage.group=Daily
|
|
- homepage.name=SearXNG
|
|
- homepage.icon=si-searxng
|
|
- homepage.description=Privacy-respecting meta-search
|
|
- homepage.href=http://10.100.50.40:9996
|
|
|
|
networks:
|
|
tnet:
|
|
name: traefik-net
|
|
external: true
|