⁠[Feature Request] 建议优化大体积配置文件解析，解决 >500KB 机场订阅无法连接的问题⁠

[mokhgi]

建议标题 (Title)

[Bug / Feature Request] 订阅配置文件体积限制导致大机场订阅无法兼容连接 ( >500KB Config Support)

问题与现象描述 (Problem Description)

目前当导入规则较多、节点较多的机场订阅链接时，由于生成的 YAML 配置文件体积较大（通常超过 500KB，部分大型机场在 1MB~3MB），软件在拉取或解析时会出现不兼容、无法加载节点或完全无法连接的问题。只有体积小于 500KB 的精简订阅才能正常工作。

使用场景与痛点 (Use Case & Motivation)

市面上绝大多数中大型机场的默认订阅文件都包含了海量规则集（Rule Set）和节点，文件大小普遍高于 500KB：

1. 解析/内存超限：大文件导入时可能触发内存壁或解析超时，导致内核初始化失败。
2. 连接失效：由于无法完整解析大于 500KB 的配置，导致节点列表为空或无法建立代理连接。

期望的解决方案 (Proposed Solution)

1. 优化配置文件解析器：在客户端导入时增加对大文件 YAML 的优化解析机制（或流式解析），避免一次性加载过多规则挤爆内存。
2. 规则裁剪/预处理 (Rule Pruning)：支持在拉取订阅时自动过滤/裁剪无用规则，或引入规则集外部加载机制，减少单文件体积。
3. 提高文件大小容错：优化内核对 1MB~5MB 范围内常态订阅配置文件的兼容支持。

其他补充 (Additional Context)

• 目前在 Apple TV 和 iOS 端使用大型机场订阅时该问题较为明显，希望能针对配置文件的体积容错进行优化，非常感谢！

[TokenPLS]

https://clash.md/zh/guide/config/best-practice
建议机场和用户阅读最佳实践。

[mokhgi]

https://clash.md/zh/guide/config/best-practice
建议机场和用户阅读最佳实践。

非常理解最佳实践的初衷，精简的配置文件确实能带来更好的性能和维护体验。
不过在实际使用中，普通用户往往面临以下现实情况：

1. 无法控制订阅源：很多用户使用的是第三方商业机场或规则转换服务，其返回的原始订阅文件体积较大（包含海量节点和全量规则），用户很难直接要求服务商更改输出格式。
2. 移动端/特定平台限制：在移动端或跨平台客户端上，二次编写规则或手动拆分 ⁠rule-providers⁠ 对绝大多数普通用户来说门槛较高。
   因此，如果客户端能在解析或加载环节（如采用流式解析、异步加载或对超大 YAML 做优化）对 >500KB 的文件提供更强的容错与支持，能极大提升此类场景下的用户体验。
   希望作者能够考虑在后续版本中评估一下大文件解析的优化方案，非常感谢！

[TokenPLS]

后续我们客户端内置懒人配置功能。

[mokhgi]

后续我们客户端内置懒人配置功能。

收到，感谢维护！期待后续版本的懒人配置功能。

[TokenPLS]

iOS 1.0.6 起去掉了客户端这边 500KB 的配置大小上限，大配置交给内核处理；1.0.6 正在审核中。

[mokhgi]

iOS 1.0.6 起去掉了客户端这边 500KB 的配置大小上限，大配置交给内核处理；1.0.6 正在审核中。

非常感谢这么快速的响应和优化！原以为是内核层的内存瓶颈，没想到是客户端限制了 500KB。直接放开限制并交给内核处理的思路太棒了！

我会密切关注 1.0.6 版本的审核和发布情况，等新版本推送后我会第一时间进行测试并在此反馈验证结果。再次感谢开发者的辛苦付出！

[mokhgi]

iOS 1.0.6 起去掉了客户端这边 500KB 的配置大小上限，大配置交给内核处理；1.0.6 正在审核中。

建议标题 (Title)

[Bug / Safety] 默认配置与懒人配置下存在 DNS 泄漏风险，建议优化默认 DNS 策略

问题描述 (Problem Description)

在直接使用软件内置的默认配置或懒人配置时，测试发现存在 DNS 查询泄漏（DNS Leak）的情况。本地系统域名解析请求未被内核完全接管或分流，导致真实 IP/运营商 DNS 暴露。

测试现象与验证方法 (Steps to Reproduce & Verification)

1. 载入内置的默认配置或懒人配置并开启代理。
2. 访问 DNS 泄漏测试网站（如 ipleak.net 或 browserleaks.com/dns）。
3. 测试结果显示出了本地 ISP（运营商）的 DNS 服务器地址，未做到完全防泄漏。

期望的优化方案 (Proposed Solution)

1. 默认开启 Fake-IP / 增强模式：在默认/懒人配置的 dns 节点中，建议设置 enhanced-mode: fake-ip，避免本地发起真实 DNS 查询。
2. 完善 DNS 分流与接管：
   • 设置高隐蔽性的上游防污染 DNS（如 DoH / DoT / QUIC）。
   • 默认启用 respect-rules 或配置标准的 nameserver-policy，确保分流规则以外的域名查询走安全代理或加密 DNS。
3. 增加系统 DNS 接管开关：确保 NetworkExtension/TUN 模式能够完整拦截并重定向系统 53 端口的 UDP/TCP 流量。

其他补充 (Additional Context)

• 代理工具在默认状态下的 DNS 隐私保护至关重要，希望能优化内置配置的 DNS 逻辑，感谢开发者的付出！