searxng: google retry 패치 시도·롤백 기록 (lite-shell은 IP당 rate, 단일IP 재시도로 해결 불가, ~100%엔 egress IP 풀 필요)

services/searxng.md

@@ -73,7 +73,13 @@ Go + [[https://github.com/refraction-networking/utls|utls]] 기반 MITM forward
 >
 > 결과 — google 포함률: **0% → 격리 라이브 ~83%, 전체검색 ~40~50%**. 결과 품질은 정상.
 >
-> **남은 한계**: 전체(다엔진 동시) 검색에서 google이 절반가량 누락. raw fetch는 100%인데 라이브 엔진은 변동 — 프록시 경유 google이 타 엔진보다 느리고 + 엔진의 정확한 요청 패턴에 Google이 간헐적으로 lite-shell을 반환하는 SearXNG↔Google 고질 변동. **추가 개선 후보**: google.py response()에서 결과 0 + lite-shell 감지 시 예외 발생시켜 SearXNG 재시도 유도하는 파서 패치(uaPatch와 동일한 sed 주입 메커니즘 활용 가능). brave/duckduckgo/qwant는 정상.
+> **남은 한계 — 근본 원인 규명 (2026-06-10 추가 조사)**: lite-shell은 **프록시 IP당 rate 기반**이다. 간격을 둔 단일 요청은 GSA·엔진형 파라미터 모두 data-ved HTML 100%(8/8) 반환하지만, 짧은 시간 내 다수 요청(burst)이면 Google이 해당 IP에 lite-shell(data-ved 없음)을 반환 → 파서 0건. 즉 정상 저빈도 사용은 대체로 정상, 고빈도/burst에서만 누락.
+>
+> **재시도 패치 시도 → 실패·롤백 (2026-06-10)**: google.py `response()`에 lite-shell 감지 시 동일 요청을 프록시로 백오프 재시도하는 래퍼를 주입(`googleRetryPatch`, configmap-google-patch + deployment command 래핑으로 실행 배선). 단일 강제-empty 테스트는 재시도로 10건 확보 성공했으나, **실사용 검증 실패**: lite-shell이 IP당 rate 기반이라 초기 요청과 재시도가 같은 rate-limit 윈도우를 공유 → 재시도가 무효일 뿐 아니라 Google 요청량을 (1+maxRetries)배로 늘려 rate-limit을 **악화**(burst 전체검색 포함률 0/12로 더 나빠짐). **결론: 단일 egress IP로는 클라이언트 재시도로 rate-limit을 이길 수 없다.** `googleRetryPatch.enabled: false`로 롤백, 템플릿은 보존.
+>
+> **~100% 달성의 진짜 조건**: egress IP 풀(여러 tlsproxy IP 로테이션). zlambda 단일 IP로는 한계. SearXNG 자체엔 빈-결과 in-search 재시도 없음(네트워크 `retries`는 HTTP 에러에만 동작). 현실적으로는 저빈도 사용 시 대부분 정상이므로 현 상태 수용 + brave/duckduckgo/qwant 보강으로 운용.
+>
+> 참고: SearXNG google 0건은 프로젝트 전반의 고질 이슈 (공식 #5286→PR#5644가 GSA UA로 전환한 것도 같은 맥락, 메인테이너가 "임시방편, 곧 패치될 것"이라 명시). #5867 HTTP 403, #5852 News 구조 변경 등.
 
 ### SearXNG 설정