网客指南 标志网客指南Windows / macOS / Android / iOS 设备网络与客户端支持
Clash Verge Rev · Clash Verge Rev / 核心崩溃 / 日志

Clash Verge Rev 核心崩溃：启动报错与日志定位

更新于 2026/8/9

获取首个错误

打开应用日志，定位第一次出现的 error 或 panic，而不是最后一条“退出”。记录核心版本、系统版本与配置更新时间。

常见修复

  1. 退出程序，备份配置目录后恢复为最小配置。
  2. 检查 YAML 缩进、重复端口和未知字段；尤其注意粘贴时的全角冒号。
  3. 让应用重新下载官方核心，确认安全软件没有隔离可执行文件。

仍然崩溃

用空白配置能启动而订阅配置不能，说明问题在配置内容；逐段恢复规则以定位。不要从不明来源下载“修复核心”。

别把“核心通信错误”等同于“核心崩溃”

Clash Verge Rev 的公开问题 #7477 报告过一种相反情况：核心实际已启动、端口在监听且流量可以转发，但前端仍显示 core communication error、代理列表为空。因此首要证据是进程、监听端口和日志的时间顺序，而不是 UI 文案。

Windows 可先执行下列只读检查（将端口替换为自己的 mixed-port）：

Get-Process | Where-Object { $_.ProcessName -match 'verge|mihomo' }
Get-NetTCPConnection -State Listen | Where-Object { $_.LocalPort -eq 7890 }
Get-Content "$env:APPDATA\io.github.clash-verge-rev.clash-verge-rev\logs\*.log" -Tail 120

脱敏后的日志应保留版本、时间和错误类型，例如：

INFO  core launched pid=[pid]
INFO  mixed proxy listening at 127.0.0.1:[port]
ERROR frontend cannot reach core control channel

若监听存在且手动代理可工作，优先按“前端/服务模式控制通道”处理：更新到维护版本、退出服务模式后复测、提交可复现日志。若进程在首个配置解析错误后退出，才回到 YAML 字段与核心版本兼容性检查。

诊断范围

“Clash Verge Rev 核心崩溃：启动报错与日志定位”应先按可观察现象缩小范围：解决 Clash Verge Rev 打不开、核心反复退出、配置加载失败的基础检查流程。 记录发生时间、使用的客户端与系统版本、是否仅在某个网络或某个配置下发生。不要从单次测速、单个节点或一次重试直接推断根因，也不要在未备份配置时同时修改多个开关。

操作步骤

  1. 保留错误提示的非敏感部分，并记下当前客户端、系统、网络类型和最近一次成功时间；订阅链接、账号、令牌和个人网络标识不得写入截图或工单。
  2. 在受控条件下只改变一个变量，例如切换已知可用的网络、恢复一份已导出的配置，或暂时停用可能重复接管流量的另一个客户端；每次改动后回到同一个操作复测。
  3. 将结果归为“现象消失、现象不变、出现新错误”之一。前两类分别保留变更前后记录；出现新错误时立即恢复上一步，而不是继续叠加 DNS、代理模式、内核或系统权限改动。

验证与回退

完成调整后，以原始失败动作连续复测，并确认目标功能恢复而不是只看到界面状态改变。若复测失败，回退到已导出的配置或原先已知可用的客户端状态，再依据记录选择下一项检查。任何无法解释的证书、权限、路由或账户提示都应停止扩大改动范围并转交产品或网络管理员。

来源与适用边界

本页的“证据与参考”只用于说明已公开的配置说明或个案范围；它不能证明你的网络、账号、节点或服务端当前处于同一状态。将日志中的令牌、订阅地址、账户资料和网络标识删除后再用于比对。

来源与更新

本文的实际现象与命令依据下列公开来源整理；示例中的地址和标识符均已脱敏。

排查顺序

  1. 记录症状确认客户端、系统、错误文本与发生范围。
  2. 低风险核对先检查本文对应的配置、权限、网络或版本条件。
  3. 复测与回退只改变一项；现象变化后再决定是否继续。

常见问题

重装能解决核心崩溃吗？

有时能，但损坏的用户配置可能会被保留；应先备份并查看日志首个错误。

为什么升级后突然打不开？

核心版本变更可能不兼容旧字段或旧内核，需检查发布说明和配置语法。

确认结果、回退与日志

每次只修改一项并复测原始现象。若出现新错误，恢复导出的配置或关闭刚启用的开关；仍未解决时，请保留客户端与系统版本、错误文本、发生时间、已尝试步骤以及脱敏日志。

不要公开订阅地址、账号或完整连接信息。文中的命令与配置片段仅适用于其标注的客户端和系统；未提供命令时，请以来源中的官方界面或系统文档为准。

相关文章

Clash Verge RevClash Verge Rev 内核通信错误且代理组为空：Windows 服务模式排查基于 Clash Verge RevClash Verge RevClash Verge Rev 启动报错：端口占用、权限与配置修复针对启动即退出、端口占用、权限不足和配置读取错误的排障指南。

还没有定位到现象？

返回“Clash Verge Rev”搜索结果 →

补充更新（核对日期：2026-10-19）

更新于 2026-10-19 · netcli.net

简答：如果 Clash Verge Rev 启动即闪退，先不要重装：记录应用日志中第一次出现的 error、panic 或 failed，再用最小配置验证。若界面提示“内核通信错误”但代理仍能使用，优先检查服务模式、IPC 通道和代理组接口，不要直接把它判断成核心崩溃。

定义：“核心崩溃”是 mihomo 或 verge-mihomo 进程启动后退出；“内核通信错误”则是界面无法通过 IPC 或控制接口取得核心状态，核心本身可能仍在运行。

先按现象分流：不要把所有报错都当成核心崩溃

先观察故障发生在哪一层：双击后完全没有窗口，通常先查界面进程或应用日志；窗口能打开但马上退出，重点查核心启动和配置验证；窗口正常但代理组为空、首页显示“内核通信错误”，则要检查核心是否运行、服务模式是否可用，以及界面到核心的 IPC 通道是否正常。

Clash Verge Rev 启动故障快速对照
现象优先查看第一步暂时不要做
双击无反应或界面闪退应用日志、系统进程、最近升级记录备份应用目录后启动一次并读取最新日志不要先删除全部配置
启动后核心反复退出验证失败、YAML 错误、端口占用、核心文件用最小配置启动并记录首个错误不要同时修改 DNS、TUN 和代理模式
代理组为空且提示内核通信错误核心进程、服务日志、IPC、runtime config确认核心是否实际运行，再判断通信通道不要仅凭首页提示判定核心崩溃
TUN 开启后断网服务权限、虚拟网卡、路由和 DNS关闭 TUN 做一次对照测试不要把 TUN 断网直接归因于订阅失效

公开问题记录中存在“核心实际运行、端口正在监听，但界面仍显示内核通信错误且代理组为空”的情况，因此“通信错误”与“核心已退出”必须分开验证。GitHub 公开问题记录

第一步：取得应用日志、核心日志和服务日志

能打开客户端时，先在设置中打开日志目录或查看日志页面，复现一次故障，然后只截取从启动到第一次报错的片段。优先搜索 error、panic、failed、验证失败、runtime config、IPC 和 connection，不要只复制最后一条“退出”记录。

官方代码将应用日志、服务日志和 sidecar 日志区分处理：Windows 的应用数据目录通常位于 %APPDATA%\io.github.clash-verge-rev.clash-verge-rev；macOS 位于 ~/Library/Application Support/io.github.clash-verge-rev.clash-verge-rev；Linux 使用 $XDG_DATA_HOME/io.github.clash-verge-rev.clash-verge-rev，通常是 ~/.local/share/...。应用目录中还包括 logs/、service-logs/、配置和核心运行文件，具体文件名会随版本和运行模式变化。官方隐私说明中的数据目录与日志说明 官方源码中的日志目录定义

如果客户端完全打不开，先备份应用数据目录，再从最近修改的日志文件读取启动阶段信息。不要直接删除原目录；需要测试空白配置时，应将原目录改名保存，例如 io.github.clash-verge-rev.clash-verge-rev.backup，确认结果后再决定是否恢复。

  • 应用日志：适合查看配置生成、版本、权限、服务调用和界面层错误。
  • sidecar 日志：适合判断非服务模式下核心是否启动、读取配置或监听端口。
  • service 日志：适合判断服务模式、TUN、权限和 IPC 是否正常。
  • 临时验证日志：配置验证失败可能先写入应用日志，而不是核心长期运行日志。

第二步：用最小配置区分配置错误和核心错误

先退出 Clash Verge Rev，复制保存配置和订阅文件，再暂时移出最近更新的配置或配置组。使用空白或最小配置启动一次：如果最小配置可以启动，故障大概率在原配置内容、字段兼容性、Provider 引用或端口设置；如果最小配置仍然崩溃，再转向核心文件、权限、服务或版本问题。

  1. 记录客户端版本、核心名称或版本、系统版本，以及最后一次正常启动时间。
  2. 备份应用数据目录，不要把订阅链接、Token、密码和节点信息直接发给他人。
  3. 只保留一个最小配置，先删除最近新增的规则、Provider、脚本和复杂代理组。
  4. 检查 YAML 缩进、冒号、引号、列表层级，以及是否混入全角符号。
  5. 检查字段是否属于当前核心支持的格式；无法从当前日志确认的字段，不要凭猜测改名。
  6. 逐段恢复配置，每次只恢复一组内容；哪一步重新出现错误，就保留该次前后的日志。

如果日志出现具体的行号或字段名，应先修复该行，再验证一次。若只出现“配置验证通过”但随后出现 failed to get runtime config 或 IPC 连接失败，则不能继续把问题归因于 YAML，需要检查核心是否真的启动以及界面是否能访问控制通道。公开问题中就有“配置验证通过后仍无法取得 runtime config”的记录。GitHub 公开问题记录

第三步：检查 Windows 进程、端口和服务模式

Windows 下可用 PowerShell 或命令提示符执行以下只读检查。先关闭 Clash Verge Rev，再重新启动一次后立即执行，避免多个残留核心进程互相干扰。

tasklist | findstr /I "clash verge mihomo"
netstat -ano | findstr LISTENING

第一条用于确认界面、服务或核心进程是否存在；第二条用于观察监听端口及 PID。若怀疑某个 PID 属于残留进程，可执行：

tasklist /FI "PID eq 1234"

把 1234 换成实际 PID。不要只看到端口监听就认定界面通信一定正常：核心可能在监听代理端口，但控制接口或 IPC 仍不可用。

如果启用了服务模式或 TUN，重点看日志中是否出现服务 IPC 路径不存在、权限拒绝、读取响应失败、服务未安装或服务重启失败。若关闭 TUN、改用非服务模式后核心可以正常启动，说明下一步应集中检查服务权限、虚拟网卡和 IPC，而不是继续修改订阅。

若同一端口被多个进程占用，先退出其他客户端和残留核心，再重新启动；不要一边保留多个客户端，一边同时修改系统代理、TUN 和端口，否则无法判断是哪一个变量造成变化。

第四步：处理“内核通信错误”、代理组为空和 runtime config 失败

按下面顺序判断：

  1. 先看核心是否存在：日志或任务管理器中确认 mihomo、verge-mihomo 或对应核心进程是否启动。
  2. 再看代理端口：确认配置中的混合端口或其他监听端口没有被其他程序占用。
  3. 再看控制通道：搜索 IPC、failed to get runtime config、/version、/proxies、connection error 和 pipe。
  4. 最后看运行模式：记录当前是服务模式还是 sidecar 模式，做一次单变量切换后复测。

如果核心进程和代理端口都正常，但首页仍显示通信错误，可能是界面到核心的控制接口异常；如果核心进程不存在且日志显示服务启动失败，则更接近核心或服务启动故障。Windows 公开问题中曾记录服务模式下核心正在运行、命名管道正在监听、代理流量也能转发，但前端仍显示通信错误，因此应保留“核心正常、界面通信异常”这一分支。Windows 服务模式公开问题

不要为了“修复通信错误”随意开启外部控制接口或公开监听地址。先使用客户端现有的服务模式、日志和设置完成定位；只有在官方文档或当前版本界面明确提供对应选项时，才按原文设置。

第五步：升级后才崩溃时，先记录版本再回退

如果故障紧跟一次升级出现，记录升级前后版本、安装方式、系统版本和首次复现时间。官方变更记录显示，某些版本会涉及 Windows 服务权限、安装服务失败、macOS 内核启动、TUN、网络初始化以及服务模式停止重启等问题，因此升级后的故障应优先与版本变化对照，而不是直接判定配置损坏。官方版本变更记录

  1. 先备份配置、日志和当前版本信息。
  2. 确认问题是否只在新版本出现，旧版本是否曾经正常运行。
  3. 只回退一个变量：版本不变时不要同时更换订阅、核心、DNS 和 TUN。
  4. 回退后用同一份最小配置复测，再逐步恢复原配置。
  5. 如果新版本能启动但服务或 TUN 不工作，记录服务状态和日志，不要把“界面能打开”当成网络已恢复。

回退测试的目的不是长期停留在旧版本，而是判断问题属于版本回归、服务环境还是配置内容。若回退不能复现，而升级后稳定复现，应在反馈中附上两个版本的启动日志和最小复现步骤。

最后的复现与反馈清单

提交问题前，至少保留以下信息：客户端版本、核心版本或名称、Windows/macOS/Linux 版本、服务模式或 sidecar 模式、TUN 是否开启、最后一次成功时间、最近一次升级时间、首个错误前后各几行日志，以及是否能用最小配置启动。

发布日志前必须脱敏：订阅地址和 Token、账号、密码、节点域名或 IP、UUID、内网 IP、用户名路径、浏览目标和自定义脚本都不要原样公开。官方说明也提醒，配置和日志可能包含订阅凭据、代理服务器、访问域名及连接元数据。官方隐私说明

可以使用下面的简短模板整理证据：

客户端版本：填写实际版本
核心：填写实际名称或版本
系统：填写实际系统版本
运行模式：服务模式 / sidecar
现象：闪退 / 核心退出 / 代理组为空 / 内核通信错误
最后一次正常时间：填写日期和时间
升级或改配置时间：填写日期和时间
首个错误：粘贴脱敏后的第一条 error、panic 或 failed
最小配置结果：能启动 / 仍失败

常见问题

Clash Verge Rev 显示“内核通信错误”，是不是核心已经崩溃？

不一定。先确认 mihomo 或 verge-mihomo 进程是否存在、代理端口是否监听，再查看 IPC、runtime config 和服务日志。若核心仍能转发流量，问题可能在界面与核心之间的控制通道。

代理组为空，但系统代理似乎还能使用，应该怎么查？

先不要重装。检查核心进程、代理端口和服务模式，再查看是否出现 /proxies、/version、runtime config 或 IPC 失败。核心运行而代理组为空时，应优先按通信异常排查。

最小配置能启动，原来的配置一导入就崩溃怎么办？

保留最小配置作为基线，逐段恢复代理组、Provider、规则和脚本，每次只恢复一项。出现错误后对比本次新增内容，并根据日志中的字段或行号修复，不要一次性重写整个配置。

升级后 Clash Verge Rev 才开始闪退，应该先回退还是重装？

先备份配置和日志，记录升级前后版本，再用同一份最小配置做单变量回退测试。若旧版本恢复而新版本持续失败，反馈时附上两个版本的日志；重装前不要删除唯一的配置和证据。

日志可以直接发到论坛或群里吗？

不建议。先删除订阅链接、Token、账号、密码、节点地址、UUID、内网 IP、个人路径、访问域名和自定义脚本，只保留错误类型、时间、版本和必要上下文。

相关阅读

参考资料

  1. Clash Verge Rev GitHub：Windows 服务模式下核心运行但界面提示内核通信错误
  2. Clash Verge Rev GitHub：failed to get runtime config 与 IPC 连接失败案例
  3. Clash Verge Rev 官方隐私说明：应用数据、配置与日志目录
  4. Clash Verge Rev 官方源码：应用、服务和 sidecar 日志目录定义
  5. Clash Verge Rev 官方版本变更记录：服务、TUN 与内核启动修复

补充更新：先判定是哪一种崩溃

更新于 2026-10-24 · netcli.net

简答：Clash Verge Rev 核心崩溃时，先备份并看首个 error、panic 或解析错误，再按进程、端口、配置和控制通道四项对照，最后用最小配置复测。

定义：Clash Verge Rev 核心崩溃，是指内置 Mihomo 核心启动后退出、配置无法加载，或核心运行状态异常导致前端无法建立控制通信。

先看这张四项速查表：进程、端口、配置、控制通道

启动即退出、界面提示核心通信失败、换订阅后才崩溃，通常不是同一种故障。先看核心进程是否存在，再看监听端口，随后用最小配置复测；不要一开始就重装。

最快判断顺序：先看进程在不在，再看端口是否监听，接着排除配置，最后核对控制通道。

Clash Verge Rev 核心崩溃四项对照
观察维度看到的现象优先处理
核心进程启动后立即消失，日志出现 panic 或退出信息保留首个错误，检查核心文件、权限和安全软件隔离记录
监听端口出现 address already in use、bind 或 listen记录原端口，用命令查占用 PID，再处理重复实例或端口冲突
配置内容出现 YAML、unknown field 或解析行号恢复最小配置，再按代理、代理组、DNS、规则和 Provider 逐段恢复
控制通道核心进程存在，但界面显示 core communication 或 connection refused核对 external-controller、端口、secret、服务模式和日志时间

诊断前先复制配置目录和当前日志。配置、订阅缓存、日志和核心运行文件可能包含订阅令牌、节点地址、密码、UUID、请求域名或连接元数据，提交前应脱敏。可参考Clash Verge Rev v2.5.8 隐私说明。

跨平台日志、进程和端口检查：以当前版本为准

菜单名称可能随版本变化，优先使用应用内“打开应用目录”或日志入口。v2.5.8 的源码将应用日志放在 logs/latest.log，核心日志根据运行模式分别位于 logs/sidecar/sidecar_latest.log 或服务日志目录下的 service/service_latest.log；旧版本路径可能不同，应以当前安装版本为准。参考v2.5.8 目录与日志路径源码。

  • Windows：先执行 tasklist | findstr /i "clash verge mihomo" 查看进程，再执行 netstat -ano | findstr LISTENING 查看监听端口。若使用服务模式，可执行 sc query type= service state= all | findstr /i "clash verge"；需要修改服务或安装组件时，再按系统提示使用管理员权限。
  • macOS：从应用菜单或设置中打开应用目录，查看 logs/latest.log、logs/sidecar/，服务模式还要查看应用数据目录下的 service-logs/。终端可执行 ps aux | grep -Ei "clash|mihomo" 和 lsof -nP -iTCP -sTCP:LISTEN。
  • Linux：查看应用数据目录下的 logs/、sidecar/ 或 service/。进程检查使用 ps aux | grep -Ei "clash|mihomo"，端口检查使用 ss -ltnp；查看其他用户进程时使用 sudo ss -ltnp。如果由 systemd 管理，必须把实际服务名代入 systemctl --user status <服务名>。

导出日志时先记录故障发生时间，只保留首个错误前后的必要上下文。若应用可以打开，可从当前版本的诊断或日志入口导出；提交前删除订阅 URL、Token、密码、UUID、服务器地址和完整访问记录。

最小配置与核心类型对照：先备份，再逐段恢复

  1. 退出 Clash Verge Rev，复制应用数据目录、配置、订阅信息、覆写、脚本、Provider 和日志；修改端口或核心类型前，记录原值。
  2. 在设置中的核心选择入口记录当前核心类型。Clash Verge Rev v2.5.8 的源码列出 Mihomo 与 Mihomo Alpha 两个可切换核心，对应 verge-mihomo 和 verge-mihomo-alpha。必要时切换另一核心做对照，但每次只改变一个变量。参考v2.5.8 核心选择源码。
  3. 创建或恢复最小配置，只保留当前核心支持的基本字段和一个已知可用的代理条目，不要把完整订阅、旧版字段、脚本和 Provider 一次性放回。
  4. 如果最小配置能启动，按“代理节点—代理组—DNS—规则—Provider—脚本”的顺序逐段恢复，每次只恢复一类内容，并记录日志变化。
  5. 如果最小配置仍退出，优先检查核心文件、运行权限、服务模式、安全软件隔离记录和磁盘状态，不要继续修改原配置。

需要确认实际核心和控制端口时，可在当前配置中查看 external-controller 与 secret。mihomo 文档说明，前者定义 API 监听地址，后者是 API 访问密钥；不要把 secret 粘贴到截图、工单或公开日志中。参考mihomo 全局配置文档。

若已知控制端口和 secret，可在本机执行以下对照命令：curl -H "Authorization: Bearer <secret>" http://127.0.0.1:<端口>/version。其中 <端口> 和 <secret> 必须替换为当前配置值；接口无法访问时，先回到进程、监听端口和服务模式检查。请求头格式和 API 用法参考mihomo API 文档。

哪些文件能清理，哪些文件不要删除

清理前先关闭客户端并备份整个应用数据目录。可以优先清理旧日志或日志目录中的历史文件；Clash Verge Rev 的隐私说明也说明日志存在自动清理机制。订阅缓存只有在已确认是可重新下载副本、并且已经保存订阅地址或备份时才考虑清理。

核心崩溃后的文件处理建议
文件或目录处理建议回退方式
logs/、service-logs/保留故障时间段后，可清理历史日志需要复盘时从备份目录还原
订阅缓存或下载副本确认可重新下载且已保存地址后再清理重新更新订阅或从备份恢复
profiles、profiles.yaml不要直接删除，可能包含配置和订阅引用从整目录备份还原
覆写、脚本、Provider不要与日志一起批量删除，先单独备份逐项复制回原目录并复测
config、应用设置文件不要直接清空，可能包含核心类型、端口和运行模式关闭客户端后用备份整目录还原

如果要验证是否为缓存或运行文件损坏，应采用“备份—清理一类文件—启动—记录结果”的顺序，而不是删除整个应用数据目录。任何清理动作都要保留原目录名称或压缩备份，便于回退。

截至 2026 年 10 月 24 日的版本核对

截至 2026 年 10 月 24 日，官方 Releases 页面将 Clash Verge Rev v2.5.8标记为 Latest，页面显示发布时间为 2026 年 10 月 9 日。v2.5.8 的发布说明包含已有核心进程阻止启动、Windows 升级后权限异常无法启动、Windows 服务启动类型异常，以及 macOS 退出后 DNS 状态等修复；遇到启动崩溃时，应先对照当前版本发布说明，再决定升级或回退。参考Clash Verge Rev v2.5.8 官方发布页。

v2.5.4-rc 页面明确标记为 Pre-release，不能与正式版 v2.5.4 混写。若需要核对旧版本差异，应分别查看v2.5.4-rc 发布页和v2.5.4 正式版发布页。

若核心已经正常运行、代理请求也能通过，但只有特定服务仍然慢或丢包，应再用多个网络、设备和其他网站做对照；不应通过改变地区规避限制。

常见问题

Clash Verge Rev 核心崩溃时，当前最新稳定版是什么？

截至 2026 年 10 月 24 日，官方 Releases 页面标记 v2.5.8 为 Latest；v2.5.4-rc 是预发布版本。升级前仍应备份配置，并先对照发布说明。

Clash Verge Rev 怎么确认实际使用的是 Mihomo 还是 Mihomo Alpha？

在设置中的核心选择入口查看当前类型，也可查看配置中的核心字段。v2.5.8 源码列出 Mihomo 和 Mihomo Alpha 两个选项；切换后应重启核心并重新查看日志。

Clash Verge Rev 核心通信失败一定是核心崩溃吗？

不一定。核心可能仍在运行，但前端连接了错误的控制端口、secret 不匹配、服务模式异常或权限不足。先查进程、监听端口和 external-controller。

核心崩溃后可以直接删除 profiles 和 config 吗？

不建议。profiles、profiles.yaml、覆写、脚本和 config 可能包含订阅引用、端口、核心类型及运行设置。先备份整目录；优先清理历史日志，订阅缓存也要确认可重新下载后再处理。

Windows、macOS、Linux 的日志路径完全一样吗？

不一样。v2.5.8 源码显示应用日志为 logs/latest.log，核心日志会按 sidecar、service 和操作系统使用不同目录；菜单和旧版本路径可能变化，应从应用内打开目录并核对当前版本。

如何用 curl 检查 Clash Verge Rev 的核心是否真的运行？

先从当前配置读取 external-controller 和 secret，再执行 curl -H "Authorization: Bearer <secret>" http://127.0.0.1:<端口>/version。不要公开 secret；若请求失败，先检查端口监听和控制通道配置。

相关阅读

参考资料

  1. Clash Verge Rev v2.5.8 官方发布页
  2. Clash Verge Rev v2.5.4-rc 官方发布页
  3. Clash Verge Rev v2.5.4 正式版发布页
  4. Clash Verge Rev v2.5.8 目录与日志路径源码
  5. Clash Verge Rev v2.5.8 核心选择源码
  6. Clash Verge Rev v2.5.8 隐私说明
  7. mihomo 全局配置文档
  8. mihomo API 文档

命令诊断后的下一步

网络命令行决策：保留诊断记录；当结果指向跨境路径时，再评估网络服务。保留诊断结果并访问官网

套餐、价格、线路与规则不在本站转述，请直接核对官网当前页面。
读者交流群（Win · Mac · 安卓 · iOS 客户端排障）：t.me/netcli_chat