xiaoshuai/oc - oc - Gitea: Git with a cup of tea

xiaoshuai/oc

Fork 0

Commit Graph

Author	SHA1	Message	Date
xiaoshuai	d6e29cbbad	searxng-search: record that no domestic-only engine set works here Asked for a domestic-only default, so every general-web index SearXNG ships for China was added to keep_only, the container was restarted, and each was measured over 5 runs per query. None of them is usable. The default stays bing,yandex. engine en hits zh hits outcome 360search 5/5 5/5 reliable, 0% relevant quark 0/5 0/5 rate-limited dead after two good responses baidu - 0 CAPTCHA, 1h IP suspension sogou - 0 upstream AttributeError baidu kaifa - 0/10 code index: "opencode v2" matches OpenCV2 bilibili - - video titles, not a web index chinaso news - - falls through to the default engine set quark was the one that looked like the fix. On its first two requests it returned the exact article being asked about as result #1 on both the Chinese and the English query -- better than anything else measured -- and then answered 0 results on 5 consecutive runs of each. Had it not been run 5 times, it would have looked like the obvious upgrade. baidu kaifa is worth remembering as a category error: it is a code search index, so it matches "opencode v2" against OpenCV2 and returns CSDN blog posts at 0% relevance. It is reachable and does not CAPTCHA, which makes it look healthy in /config while being useless. The foreign engines that were reachable (brave, duckduckgo, google, qwant, wikipedia) were added at the same time and all returned 0, consistent with the network timeouts already recorded in settings.yml. mojeek and startpage are not present in this SearXNG release at all, so the earlier note calling them "unreachable" was imprecise. settings.yml was restored from a backup and diffed byte-identical before this commit; the probe engines never left the instance. cn.bing.com is the only dependable endpoint and is a China-hosted Bing, so bing counts as the domestic option. Its one real limitation stands: it ignores the site: operator, so site-restricted search is unavailable through this instance. Also fixes a duplicated `bing` row left in the README engine table by the previous commit.	2026-10-08 13:44:46 +08:00
xiaoshuai	aa70b381bf	searxng-search: default engines bing,yandex instead of bing,360search The default was chosen by a single Chinese test query and generalized from it. Measuring both a Chinese and an English technical query shows it was inverted on both counts. Results mentioning "opencode", out of returned: zh "OpenCode V2 和 V1 区别" en "opencode v2 migrate from v1 plugin api" bing 10/10 missed the doc entirely 360search 0/5 4, unrelated (sohu/toutiao) yandex 14/15 15, migration doc ranked #1 naver 0/9 15, migration doc ranked #1 yandex had been excluded on the claim that it "has almost no Chinese index". Measured, it has the best Chinese relevance of any engine here, and on the English query the V1->V2 migration doc is its first result -- the exact document that the old default could not find at all. 360search had been the default. It is the worst engine on both query types. It splits the query on "V1"/"V2" and answers with Android and CANN version-difference articles, which produced the 10-of-15 noise in the first round of testing. naver is left out rather than added: strongest on English, 0/9 on Chinese, so including it would trade one kind of noise for another. It is documented as worth passing explicitly for English lookups. The comment above the constant now carries the measurement table, so the default can be re-chosen from data instead of re-derived from a hunch. Not changed, and worth knowing: cn.bing.com ignores the site: operator. engines=bing&q=site:opencode.ai+v2+migration returns 0 results from opencode.ai, while the same query without site: returns 3. Site-restricted search is not available through this instance. Unreproduced: one run of the Chinese query returned entirely unrelated results from bing (Doubao, Zhipin, Zhihu) while four other runs with the same parameters returned 10/10 relevant. No parameter difference was found between the good and bad runs. Treated as transient upstream behaviour, not a plugin bug, and not documented as a rule. README engine table updated to the measured numbers.	2026-10-08 13:35:57 +08:00
xiaoshuai	9e10925023	searxng-search: document the plugin and how the instance was deployed Two docs next to the plugin: README.md for the tool, SEARXNG-SETUP.md for the Docker deployment behind it. Both are written from measurements against the running instance, not from a guide. The setup doc exists because the deployment decisions were only recorded as comments inside settings.yml, which means they are unfindable unless you already know to look there. It also records the parts that are not guessable: why the port is 39217, why limiter is off, why the UI locale is zh-Hans-CN rather than zh-CN, and which engine is broken how. Corrections found while writing it: - The rebuild steps pointed at searxng/searxng-docker, which is superseded. That repository now holds only a deprecation notice and its docker-compose.yml raw URL 404s. The templates moved to searxng/master/container/. Verified both local files are byte-identical to the current templates, so the deployment was always the current one -- only the documented URL was wrong. - The plugin README claimed the entrypoint comes from package.json. This directory has no package.json; the entrypoint falls back to index.ts. Restarted the service with both .md files in place to confirm they do not affect resolution. Documents the two SearXNG behaviours that fail silently rather than loudly, both verified by reading the engine label on each result: - An unknown engine name is ignored and the default engine set is searched instead, with no error. engines=mojeek returns 10 bing results and looks like a success, as does a typo. The only reliable signal is whether the requested engine appears in results[].engine. - /config is not a way to check this. It reported disabled: false for every engine while baidu and sogou were in fact being dropped, because it reflects upstream defaults and not the local disabled: true overrides. Also records that ctx.options is always {} for a directory-discovered plugin, so the four options in PluginConfig cannot be supplied without moving the plugin out of plugins/ and registering it in opencode.jsonc. Verified by writing JSON.stringify(ctx.options) to a file from inside setup(). No secret_key value is in either file; settings.yml stays outside this repository under ~/Docker.	2026-10-08 13:29:02 +08:00

Author

SHA1

Message

Date

xiaoshuai

d6e29cbbad

searxng-search: record that no domestic-only engine set works here

Asked for a domestic-only default, so every general-web index SearXNG ships
for China was added to keep_only, the container was restarted, and each was
measured over 5 runs per query. None of them is usable. The default stays
bing,yandex.

  engine          en hits  zh hits  outcome
  360search         5/5      5/5   reliable, 0% relevant
  quark             0/5      0/5   rate-limited dead after two good responses
  baidu              -        0   CAPTCHA, 1h IP suspension
  sogou              -        0   upstream AttributeError
  baidu kaifa        -      0/10   code index: "opencode v2" matches OpenCV2
  bilibili           -        -   video titles, not a web index
  chinaso news       -        -   falls through to the default engine set

quark was the one that looked like the fix. On its first two requests it
returned the exact article being asked about as result #1 on both the Chinese
and the English query -- better than anything else measured -- and then answered
0 results on 5 consecutive runs of each. Had it not been run 5 times, it would
have looked like the obvious upgrade.

baidu kaifa is worth remembering as a category error: it is a code search
index, so it matches "opencode v2" against OpenCV2 and returns CSDN blog posts
at 0% relevance. It is reachable and does not CAPTCHA, which makes it look
healthy in /config while being useless.

The foreign engines that were reachable (brave, duckduckgo, google, qwant,
wikipedia) were added at the same time and all returned 0, consistent with the
network timeouts already recorded in settings.yml. mojeek and startpage are not
present in this SearXNG release at all, so the earlier note calling them
"unreachable" was imprecise.

settings.yml was restored from a backup and diffed byte-identical before this
commit; the probe engines never left the instance.

cn.bing.com is the only dependable endpoint and is a China-hosted Bing, so bing
counts as the domestic option. Its one real limitation stands: it ignores the
site: operator, so site-restricted search is unavailable through this instance.

Also fixes a duplicated `bing` row left in the README engine table by the
previous commit.

2026-10-08 13:44:46 +08:00

xiaoshuai

aa70b381bf

searxng-search: default engines bing,yandex instead of bing,360search

The default was chosen by a single Chinese test query and generalized from
it. Measuring both a Chinese and an English technical query shows it was
inverted on both counts. Results mentioning "opencode", out of returned:

zh "OpenCode V2 和 V1 区别" en "opencode v2 migrate from v1 plugin api"
bing 10/10 missed the doc entirely
360search 0/5 4, unrelated (sohu/toutiao)
yandex 14/15 15, migration doc ranked #1
naver 0/9 15, migration doc ranked #1

yandex had been excluded on the claim that it "has almost no Chinese index".
Measured, it has the best Chinese relevance of any engine here, and on the
English query the V1->V2 migration doc is its first result -- the exact
document that the old default could not find at all.

360search had been the default. It is the worst engine on both query types.
It splits the query on "V1"/"V2" and answers with Android and CANN
version-difference articles, which produced the 10-of-15 noise in the first
round of testing.

naver is left out rather than added: strongest on English, 0/9 on Chinese, so
including it would trade one kind of noise for another. It is documented as
worth passing explicitly for English lookups.

The comment above the constant now carries the measurement table, so the
default can be re-chosen from data instead of re-derived from a hunch.

Not changed, and worth knowing: cn.bing.com ignores the site: operator.
engines=bing&q=site:opencode.ai+v2+migration returns 0 results from
opencode.ai, while the same query without site: returns 3. Site-restricted
search is not available through this instance.

Unreproduced: one run of the Chinese query returned entirely unrelated
results from bing (Doubao, Zhipin, Zhihu) while four other runs with the same
parameters returned 10/10 relevant. No parameter difference was found between
the good and bad runs. Treated as transient upstream behaviour, not a plugin
bug, and not documented as a rule.

README engine table updated to the measured numbers.

2026-10-08 13:35:57 +08:00

xiaoshuai

9e10925023

searxng-search: document the plugin and how the instance was deployed

Two docs next to the plugin: README.md for the tool, SEARXNG-SETUP.md for the
Docker deployment behind it. Both are written from measurements against the
running instance, not from a guide.

The setup doc exists because the deployment decisions were only recorded as
comments inside settings.yml, which means they are unfindable unless you
already know to look there. It also records the parts that are not guessable:
why the port is 39217, why limiter is off, why the UI locale is zh-Hans-CN
rather than zh-CN, and which engine is broken how.

Corrections found while writing it:

- The rebuild steps pointed at searxng/searxng-docker, which is superseded. That
  repository now holds only a deprecation notice and its docker-compose.yml raw
  URL 404s. The templates moved to searxng/master/container/. Verified both
  local files are byte-identical to the current templates, so the deployment
  was always the current one -- only the documented URL was wrong.
- The plugin README claimed the entrypoint comes from package.json. This
  directory has no package.json; the entrypoint falls back to index.ts. Restarted
  the service with both .md files in place to confirm they do not affect
  resolution.

Documents the two SearXNG behaviours that fail silently rather than loudly,
both verified by reading the engine label on each result:

- An unknown engine name is ignored and the default engine set is searched
  instead, with no error. engines=mojeek returns 10 bing results and looks like
  a success, as does a typo. The only reliable signal is whether the requested
  engine appears in results[].engine.
- /config is not a way to check this. It reported disabled: false for every
  engine while baidu and sogou were in fact being dropped, because it reflects
  upstream defaults and not the local disabled: true overrides.

Also records that ctx.options is always {} for a directory-discovered plugin,
so the four options in PluginConfig cannot be supplied without moving the
plugin out of plugins/ and registering it in opencode.jsonc. Verified by
writing JSON.stringify(ctx.options) to a file from inside setup().

No secret_key value is in either file; settings.yml stays outside this
repository under ~/Docker.

2026-10-08 13:29:02 +08:00

3 Commits