3. 延迟测试（只给建议，不改配置）

点击「开始测速」后，插件逐个连接每个已启用后端的服务器，测量分段耗时：

阶段	含义
连接	TCP 连接，或经代理的隧道建立（HTTP CONNECT / SOCKS5）
TLS	TLS 握手
总延迟	上述之和，加上首字节时间

它不发任何搜索请求，也不使用查询词——探测的是各服务的首页（HEAD /）。这里要回答的是「从这台机器访问这个服务有多快」，而不是「能搜到什么」。用 HEAD 而不是 GET，是因为首页动辄几百 KB，为了测延迟把七个页面都拉下来既慢又不礼貌；服务器回 405 也算可达。

排序仅按总延迟，未响应的后端排最后。插件只给建议 + 可复制的配置片段，决定权在你。

⚠️ 可达 ≠ 可用，这一点界面上也会明说。实测中：Google 返回不含结果的 JavaScript 空壳页、Yandex 返回验证码、公开 SearxNG 实例可能关闭了 JSON 输出——它们都会被测成「可达」。所以只按延迟排序，可能把一个快但搜不到东西的后端排到前面。这也是插件不自动应用建议的原因。

配置项

配置项	默认	说明
`backends`	`['bing']`	启用的后端与顺序。未知名字丢弃并告警；你给的顺序会被保留，不再重排。
`proxy`	`''`（直连）	全局代理：`http://` `https://` `socks5://` `socks5h://`
`proxyByBackend`	`{}`	按后端覆盖；`direct`/`none`/`off` = 该后端直连
`noProxy`	`[]`	始终直连的域名（父域名匹配）
`useEnvProxy`	`true`	是否读取 `HTTPS_PROXY` 等环境变量
`searxngInstances`	5 个公开实例	建议换成自己搭的
`timeoutMs`	`12000`	单请求超时（上限 60000）
`totalTimeoutMs`	`timeoutMs × 2`	整条链总预算（上限 120000）
`maxResults`	`5`	结果条数（上限 20）
`wikipediaLang`	`en`	中文用 `zh`
`takeover`	`false`	`true` = 无条件抢占搜索槽位
`digest`	`false`	`true` = 额外把结果渲染成纯文本放进 `content`

环境变量前缀 DSH_FREE_WEB_SEARCH_：BACKENDS TIMEOUT_MS TOTAL_TIMEOUT_MS SEARXNG_INSTANCES WIKIPEDIA_LANG MAX_RESULTS TAKEOVER DIGEST PROXY NO_PROXY PROXY_BY_BACKEND（形如 google=http://a:1,baidu=direct）USE_ENV_PROXY。

预算为什么是「预留式分配」

只设单请求超时不够：链上每多一个后端，最坏情况就多一份超时时间，几个后端就能把一次搜索拖到一分多钟。

但单纯共享一个 deadline 也不够——这是实测出来的：4 个后端、24s 预算时，5 个卡住的 SearxNG 实例把预算全吃光，后面三个后端全部报 skipped，根本没被尝试。这恰恰是最糟的失效模式，因为「第一个挂了、后面某个本来能work」正是这条链存在的唯一理由。

所以预算是预留式：每个后端只拿「剩余 − 给后面每个预留的一份」；快速失败把时间还回池子；预算小到无法预留时改为平均分配（短尝试还可能成功，不尝试必然失败）。

dsh-free-web-search

同名パッケージの別リポジトリ

インストール

ドキュメント

3. 延迟测试（只给建议，不改配置）

配置项

预算为什么是「预留式分配」