一句话答案：提交 GitHub Issue 前必须先检索历史已解决工单，严格遵循官方 Issue 模板填写操作系统版本与复现步骤，最重要的是必须对所有抓取的日志进行订阅与 IP 脱敏。
本文要点
- 在提交新 Issue 之前，务必使用英文或中文关键词在 Closed Issues 中检索是否存在相同问题。
- 严格按照官方模板提供：软件版本、操作系统架构、内核类型以及明确的问题复现步骤。
- 日志信息必须彻底脱敏，绝不能将个人订阅链接、节点真实服务器地址暴露在公开论坛上。
- 常见使用问题建议先查阅本站 网络排障故障中心 寻找现成方案。
高效 Issue 的基本要素与社区协作礼仪
开源社区是一个基于自愿奉献与互助的技术环境。Clash Verge Rev 的维护者通常在业余时间处理社区反馈。如果用户提交的 Issue 仅包含「为什么连不上」「软件打不开」等模糊描述，往往会被直接标记为 invalid 并关闭，无法解决任何实质问题。
一份高质量的 Bug 报告应当具备可验证性与详实性。明确指明问题发生时的客户端精确版本（如 v1.7.5）、当前运行平台（Windows 11 23H2 x64）以及激活的代理模式（系统代理或 TUN 模式），能够帮助开发者在几分钟内缩小缺陷复现范围。
| Issue 构成板块 | 正确做法（高效清晰） | 错误做法（无效反馈） |
|---|---|---|
| 标题简述 | [Bug] Windows 11 下开启 TUN 模式报 Wintun 驱动加载失败 | 软件又坏了，根本用不了 |
| 运行环境说明 | Clash Verge Rev v1.7.5 / Mihomo 内核 / Win11 Pro x64 | 最新版 / 电脑系统 |
| 复现步骤 | 1. 点击设置 2. 启用 TUN 3. 点击授权 4. 出现错误提示弹窗 | 一开就报错 |
| 日志附件 | 已过滤个人隐私的关键报错堆栈文本（Markdown 代码块） | 直接贴带自己机场订阅 URL 的完整长图 |
客户端运行日志提取与隐私敏感信息脱敏流程
在诊断复杂崩溃或内核通信异常时，运行日志是定位问题的决定性证据。Clash Verge Rev 提供了图形化的日志查看器，但直接导出的日志通常会包含客户端正在访问的域名、解析到的公网 IP 以及订阅更新接口。
在将日志复制并粘贴到 GitHub 之前，必须执行严格的脱敏过滤：使用文本编辑器的查找替换功能，将所有订阅 URL 替换为 example.com/sub，将节点 IP 替换为 1.1.1.1。泄漏个人订阅不仅会导致流量被他人盗用，还可能引发账户安全风险。
常见非代码 Bug 的本地自查与排障分流
统计表明，GitHub 上超过 70% 的 Issue 并非客户端自身代码缺陷，而是由于本地操作系统环境配置冲突或网络服务商自身故障引起的。例如端口 7890 被其他软件占用、旧版网卡驱动损坏或订阅节点本身全部下线。
在前往 GitHub 提单前，强烈建议先通过本站的现成诊断手册进行本地排查：若遇到端口占用可阅读 7890 端口冲突排查；若节点列表一片空白可阅读 节点不显示解决手册；若订阅拉取超时可参考 订阅超时排障指南。
常见问题解答
为什么我的 Issue 刚提交就被自动关闭了？
通常是因为未按照官方 Issue 模板填写必填项目（如未填写版本号），或者触发了 GitHub 机器人的关键字自动合并规则。请仔细阅读模板提示后重新补全信息。
可以在 GitHub Issue 里询问节点购买或网络服务推荐吗？
严禁询问。GitHub 官方仓库遵循开源纯洁性原则，严禁讨论商业代理买卖、特定服务商评测等违规话题，违者会被封禁账号。如需服务选型请参阅本站 网络服务推荐专区。
提交 Feature Request（新功能建议）有什么特殊要求？
提交功能建议时，应重点阐述该功能对广大用户的普遍价值与具体应用场景，并说明现有功能为何无法满足需求。
