Dashboard 0.2 (75) 已发布
https://testflight.apple.com/join/pR1xwCfB

DNS Proxy 0.1 (22) 已发布

公共更新：
1. 升级 DNS 记录模型与储存构建方法，读写操作全部移入安全并发隔离环境

Dashboard 更新：
1. macOS 版改为 TabView 控件，避免切换页面时重复创建销毁视图卡顿
2. 切换服务器时重新创建容器，避免多个服务器的数据写入同一个数据库造成混乱
3. 更新图标

DNS Proxy 更新：
1. 新增网络流管理类，统一管理流的等待队列与读写
2. 新增后台更新管理类，统一管理 DNS 记录后台更新队列
3. 重写 DNS 请求逻辑
- 初次请求（无缓存时）总是并发请求并选择最快且有效的解析结果，其余请求转到后台更新
- 有缓存时按照用户设置依照 优先级排序/最低延迟/随机 返回缓存结果，并同时将需要更新的记录加入后台更新队列
- 加入请求超时逻辑，默认 1 秒，超时取消连接不再等待剩余结果返回

Dashboard 0.3 (95) 已发布
https://testflight.apple.com/join/pR1xwCfB

Dashboard 更新：
1. 增加 Clash（Mihomo）的 “连接”查看支持
- 现在用户可以新建 Clash 类型服务器并查看“连接”了
2. （仅 iOS) 更新“概览”页面样式
- 服务器选择按钮移到了左上角
3. （仅 iOS) 更新 < iOS26 时的“聚焦”页面样式
- 现在和 iOS26 一样使用位于 Tabbar 上方的选择器

公共更新：
1. 更新 连接 记录模型与构建方式
2. 更新“连接”页面的样式，提供了更多可查看内容

⚠️ 注意，0.2 -> 0.3 版本更新了服务器信息的读写机制，之前保存的服务器会被移除，需要用户重新添加

Dashboard 0.3 (114)已发布
https://testflight.apple.com/join/pR1xwCfB

Dashboard 更新：
1. 恢复 iOS 18.6/macOS 15.6 的支持。
2. 从 HTTP API 数据清洗为自有模型时，总是增量更新已有的数据，不再暴力替换旧数据，暴力替换会导致显示不稳定的小概率崩溃问题。

公共更新：
1. 更新 连接 记录模型与构建方式
2. 更新 DNS 记录模型与构建方式
3. 更新 URL 记录模型与构建方式
4. 更新 统计 记录模型与构建方式

主要是更新了模型与读写方式来向下兼容，同时保证读写效率与稳定性。

Dashboard 0.4 (124)已发布
https://testflight.apple.com/join/pR1xwCfB

Dashboard 更新：
1. 初步增加 Surge 策略页面支持
- 目前切换策略需要在长按/右键菜单中操作
2. 与 HTTP API 的同步加入队列控制功能
3. 概览页面的面板不再寻求被动触发，改为 每秒刷新一次

详情明天写

Alhaitham Dashboard 0.4 (130)已发布
https://testflight.apple.com/join/pR1xwCfB

公共更新：
0. 初步实现 Insights 界面的搜索功能，未来聚合搜索/统计数据/查询工具等均在此页面实现。
1. 完善数据库结构，现在 Dashboard、App Proxy、DNS Proxy 三个 App 已完全数据互通。
2. 增加开发者菜单，用户可以手动还原/恢复/清空数据库，App 开启时会检测数据库加载情况。
3. 分离 V1 与 V2 版数据库，来自第三方 API 的数据现在不会和自身管理的数据相互干扰。

# Alhaitham DNS Proxy 能解决什么问题？

Alhaitham DNS Proxy 的核心价值，不只是“把 DNS 请求转发到指定上游”，而是把 DNS 解析、应用来源识别、分流策略、Fake-IP 映射 从传统 VPN 隧道中拆出来，交给专门的 DNS Proxy Provider 处理。

它更适合作为传统 VPN / Packet Tunnel 架构中的 DNS 决策层 和 **Fake-IP 映射层**，而不是单纯作为一个普通 DNS 客户端。

---

## 1. 解决传统 Packet Tunnel 难以稳定获得 App 来源的问题

传统 VPN，也就是 Packet Tunnel Provider`，主要处理的是 IP 层数据包。它能看到目标 IP、端口、协议等信息，但在很多场景下，并不能可靠知道这个连接到底来自哪个 App，也就是无法稳定获得 `bundleID / App 名称。

DNS Proxy 的优势在于：系统把 DNS 解析请求转交给 DNS 代理时，代理可以基于 DNS 请求上下文获得更多来源信息。这样在处理域名解析时，不仅能知道：

要解析什么域名

还可以进一步关联：

是哪个 App 发起的解析

因此它可以实现传统纯域名分流或纯 IP 分流很难做到的策略，例如：

同一个域名：

- App A 走普通 DNS
- App B 走 DoH
- App C 返回 Fake-IP
- 指定企业签名 App 走专用 DNS

这使 DNS 分流从“按域名”升级为：

按 App / 包名 / 发布企业 / 域名 / DNS 协议 / 策略组 多维度分流

这是 Alhaitham DNS Proxy 最重要的能力之一。

---

## 2. 缓解 Packet Tunnel Provider 的内存压力

在 iOS 上，Network Extension 进程长期受到较严格的内存限制。开发者实践中，`Packet Tunnel Provider` 常见内存上限约为 **50MB**，而 DNS Proxy Provider 常见可用内存更低，约为 **15MB**。具体限制会受系统版本、设备、扩展类型和系统策略影响。

这看起来像是 DNS Proxy 更吃亏，但从架构上看反而有价值：

如果把 DNS 解析、规则匹配、缓存、Fake-IP 分配、域名索引等工作全部塞进 Packet Tunnel Provider，隧道扩展很容易因为规则集、Geo 数据、连接表、DNS 缓存等内容占用大量内存。

Alhaitham DNS Proxy 的思路是：

Packet Tunnel Provider 专注处理流量转发
DNS Proxy Provider 专注处理 DNS 解析和域名决策

这样可以把 DNS 相关状态从传统 VPN 扩展中剥离出来，减少 Packet Tunnel Provider 的内存占用，让隧道扩展把有限内存用于更关键的连接管理、TCP/UDP 转发、路由和代理协议处理。

---

## 3. 让 Fake-IP 映射具备“域名 + App”双维度

传统 Fake-IP 方案通常是：

domain -> fake-ip

例如：

example.com -> 198.18.0.1

但这种方式有一个问题：

如果不同 App 访问同一个域名，传统 VPN 在看到 Fake-IP 回流时，只能知道它对应某个域名，却不一定知道它来自哪个 App。

Alhaitham DNS Proxy 可以在 DNS 解析阶段就建立更细粒度的映射：

domain + bundleID -> fake-ip

例如：

example.com + com.apple.mobilesafari -> 198.18.0.1
example.com + com.example.app       -> 198.18.0.2

这样，当 Packet Tunnel Provider 收到访问某个 Fake-IP 的连接时，可以通过 API 反查：

fake-ip -> domain + bundleID / App 信息

也就是说，传统 VPN 隧道即使自己无法直接可靠识别 App 来源，也可以借助 DNS Proxy 提前建立的映射关系，恢复“按 App 分流”的能力。

最终效果是：

DNS Proxy 负责识别：谁解析了什么域名
Packet Tunnel 负责处理：谁正在访问哪个 Fake-IP
两者通过 Fake-IP 映射 API 打通

这使基于 TUN / VIF 的代理架构可以获得更接近 Per-App 策略的能力，而不必完全依赖 Packet Tunnel 自身在 IP 层做 App 归属判断。

---

## 总结

Alhaitham DNS Proxy 解决的不是单一的 DNS 转发问题，而是传统 iOS/macOS 网络代理架构中的三个核心痛点：

1. Packet Tunnel 难以稳定获得 App / bundleID 来源
2. Packet Tunnel 内存有限，DNS 与规则逻辑会挤占隧道内存
3. 传统 Fake-IP 只能按域名映射，无法天然表达“哪个 App 访问了哪个域名”

通过独立的 DNS Proxy Provider，Alhaitham DNS Proxy 可以把 DNS 解析变成一个带有 App 上下文的策略入口，从而实现：

按 App 分流
按域名分流
按发布企业分流
按 DNS 协议分流
Fake-IP 反查域名与 App
与 Packet Tunnel Provider 协同工作

因此，它更适合作为传统 VPN / Packet Tunnel 架构的 DNS 决策层和 Fake-IP 映射层，而不是单纯作为一个普通 DNS 客户端。

---

## 适用场景

Alhaitham DNS Proxy 特别适合以下场景：

- 需要按照 App / bundleID 进行 DNS 分流；
- 需要让不同 App 对同一域名使用不同解析策略；
- 需要将 DNS 解析、缓存、规则匹配从 Packet Tunnel Provider 中拆分出来；
- 需要在 Fake-IP 模式下反查域名与 App 来源；
- 需要与传统 Packet Tunnel Provider 协同，实现更细粒度的代理策略；
- 需要支持多种加密 DNS 协议，例如 DoH、DoT、DoQ 等。

---

## 当前支持的 DNS 协议

Alhaitham DNS Proxy 当前支持：

- DNS over UDP
- DNS over TCP
- DNS over HTTPS
- DNS over HTTPS with authentication
- DNS over TLS
- DNS over QUIC

---

## 注意事项

通过 TestFlight 直接安装时，应用没有权限直接注册为系统 DNS 代理。

如果需要注册为系统 DNS 代理，需要使用 Debugger 安装包完成注册。通过 Debugger 安装包注册为 DNS 代理后，后续可以继续通过 TestFlight 更新和使用。

当前版本仅支持：

iOS 26、macOS 26 或更高版本

Alhaitham Dashboard 0.4 (132)已发布
https://testflight.apple.com/join/pR1xwCfB

Alhaitham DNS Proxy 0.1 (36)已发布
https://testflight.apple.com/join/r8yjKr4P

公共更新：
1. 解决了多层数据表的查询问题，从而大幅简化数据库结构，此版本可能需要清理和重建数据库并重启 app。
2. 将部分 Swift package 迁移为 原生框架目标（framework targets）
3. 解决初次安装 app 触发数据库管理/恢复界面的问题

Dashboard 更新：
1. 共享储存与外部 API 更好的隔离
2. iPad 版也支持多窗口了，允许同时连接多个服务器

DNS Proxy 更新：
1. 重构 DNS 规则为 DNS 策略数据表，准备好与 App Proxy 策略的整合工作

Alhaitham DNS Proxy 0.1 (37)已发布
https://testflight.apple.com/join/r8yjKr4P

Alhaitham Dashboard 0.4 (133)已发布
https://testflight.apple.com/join/pR1xwCfB


DNS Proxy 更新：
1. 重写 DNS 策略逻辑，现在 DNS 策略系统已经可以正常工作了，当前 DNS 策略优先级为：
- 1. DNS 策略命中规则中指定的 DNS 服务器与请求策略
- 2. 当前存在的 VIF / TUN fake-ip 用 DNS 服务器
- 3. 全局设置中的默认 DNS 服务器与请求策略
- 4. 系统默认 DNS 服务器
2. DNS 策略的 bundleID 规则现在可以精确匹配 organizationID 与 更深层的 extensionID:
- 如一条 DNS 策略中， bundleID 填写 “com.apple”, DNS 服务器填写 “https://doh.dns.apple.com/dns-query”，则全部发布在“com.apple”苹果组织下的 app 与进程与扩展，均会使用 DoH: https://doh.dns.apple.com/dns-query 作为唯一的 DNS 服务器，并绕过 VPN 的 本地 DNS 服务器。