-
Notifications
You must be signed in to change notification settings - Fork 3.7k
Open
Labels
bugSomething isn't workingSomething isn't working
Description
验证步骤
- 我已经阅读了 文档,了解所有我编写的配置文件项的含义,而不是大量堆砌看似有用的选项或默认值。
- 我仔细看过 文档 并未解决问题
- 我已在 Issue Tracker 中寻找过我要提出的问题,并且没有找到
- 我是中文用户,而非其他语言用户
- 我已经使用最新的 Alpha 分支版本测试过,问题依旧存在
- 我提供了可以在本地重现该问题的服务器、客户端配置文件与流程,而不是一个脱敏的复杂客户端配置文件。
- 我提供了可用于重现我报告的错误的最简配置,而不是依赖远程服务器或者堆砌大量对于复现无用的配置等。
- 我提供了完整的日志,而不是出于对自身智力的自信而仅提供了部分认为有用的部分。
- 我直接使用 Mihomo 命令行程序重现了错误,而不是使用其他工具或脚本。
操作系统
Windows
系统版本
Windows 11 25H2
Mihomo 版本
Mihomo Meta v1.19.20 windows amd64 with go1.25.7 Sun Feb 8 14:00:44 UTC 2026
配置文件
mode: rule
proxies:
- name: 🔗 TEST_1
server: 10.66.96.171
port: 16000
type: hysteria2
password: MTIzNDU2Nzg5MDEyMzQ1Ng==
skip-cert-verify: true
udp: true
- name: 🔗 TEST_2
server: 10.66.96.172
port: 16000
type: ss
cipher: 2022-blake3-aes-128-gcm
password: MTIzNDU2Nzg5MDEyMzQ1Ng==
udp: true
proxy-groups:
- name: 🔗 GROUP
type: fallback
url: https://www.gstatic.com/generate_204
expected-status: 204
timeout: 1000
interval: 1
max-failed-times: 2
include-all-proxies: true
rules:
- MATCH,🔗 GROUP描述
我准备了两个无法连通的节点,设置了自动Health Check,超时为1000ms,对于无法连通的节点,它偶尔可以生效,但经常会是几秒才超时。
可能是与系统的TCP/UDP超时相关?在这期间,可能Go无法打断它?有一个细节,启动后默认会选择第一个节点TEST_1,此时系统很多请求正在发往TEST_1,而恰好也是TEST_1超时有问题。
我依赖它进行自动切换,经常需要好几秒才能切换完毕,影响首次访问的体验。
重现方式
启动后,它会自己测试,输出超时日志
日志

Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
bugSomething isn't workingSomething isn't working