IP Filter 分流逻辑对比分析

点击按钮将文档导出为HTML格式（保留所有交互式流程图）

一、核心分流逻辑对比表

┌─────────────────────────────────────────────────────────────────────┐ │ IP Filter 分流决策树 │ └─────────────────────────────────────────────────────────────────────┘

Windows Native - WFP层过滤

├─ 实现方式: WFP (Windows Filtering Platform) ├─ DNS处理: DNS优先抓取 ├─ 优先级: Exclusive > Inclusive ├─ 匹配顺序: DNS流量 → Exclusive → Inclusive ├─ Inclusive为空 → 默认0.0.0.0/0 └─ 流量可返回OS ✓

Mac Native - 虚拟接口+路由

├─ 实现方式: 虚拟接口 + 系统路由 ├─ DNS处理: 全域名走虚拟接口 ├─ 优先级: Exclusive > Inclusive (物理接口优先级高) ├─ 匹配顺序: 物理接口优先级 > 虚拟接口 ├─ DNS设置影响所有域名解析 ├─ DNS Relay机制处理内网域名 └─ 流量不可返回OS ✗

Android Native - VPN Service

├─ 实现方式: Android VPN Service API ├─ DNS处理: 虚拟接口DNS ├─ 优先级: 仅支持Inclusive ⚠️ ├─ 需同时匹配: APP Filter + IP Filter ├─ Inclusive APP → 使用虚拟接口DNS ├─ Exclusive APP → 使用物理接口DNS ├─ 不支持Exclusive IP └─ 流量不可返回OS ✗

iOS IPSec / Mac IPSec

├─ 实现方式: 不支持Filter ├─ DNS处理: 不支持 └─ 优先级: 不支持

二、详细分流流程图

1. Windows Native 分流逻辑

graph TD A[网络流量] --> B{是DNS流量?} B -->|是| C[进入DP处理] B -->|否| D{在Exclusive中?} D -->|是| E[走OS物理接口] D -->|否| F{在Inclusive中?} F -->|是| C F -->|否| G{Inclusive为空?} G -->|是| C G -->|否| E style C fill:#90EE90 style E fill:#FFB6C1

2. Mac Native 分流逻辑

graph TD A[网络流量] --> B{DNS查询?} B -->|是| C[强制走虚拟接口] B -->|否| D{系统路由匹配} D --> E{接口优先级} E -->|物理接口优先级高| F{在Exclusive?} E -->|虚拟接口| G[进入DP] F -->|是| H[走物理接口] F -->|否| I{在Inclusive?} I -->|是| G I -->|否| H C --> J{Policy匹配?} J -->|否| K[DNS Relay到物理接口] J -->|是| G style G fill:#90EE90 style H fill:#FFB6C1 style K fill:#FFD700

3. Android Native 分流逻辑

graph TD A[应用流量] --> B{在Inclusive APP?} B -->|否| C{模式是Exclusive?} B -->|是| D{目标IP在Inclusive?} C -->|是| E{在Exclusive APP?} C -->|否| D E -->|是| F[走物理接口] E -->|否| D D -->|是| G[进入DP
使用虚拟接口DNS] D -->|否| F H[不支持Exclusive IP] style G fill:#90EE90 style F fill:#FFB6C1

三、关键差异对比矩阵

特性	Windows Native	Mac Native	Android Native	iOS/Mac IPSec
实现方式	WFP	虚拟接口+路由	VPN Service	不支持
优先级	Exclusive优先	Exclusive优先	仅Inclusive	-
DNS处理	独立抓取	强制虚拟接口	基于APP Filter	-
IP冲突处理	走OS	走物理接口	N/A	-
内网DNS支持	支持✓	Relay支持	需配置	-
流量返回OS	支持✓	不支持✗	不支持✗	-
默认行为	全部进DP	全部进DP	全部进DP	全部进隧道
Exclusive IP	支持✓	支持✓	不支持✗	-
APP级别控制	不支持✗	不支持✗	支持✓	-

四、平台特性详细说明

🪟 Windows Native

使用WFP在网络堆栈层过滤
DNS流量优先级最高
支持流量返回操作系统
Exclusive优先于Inclusive
内网DNS完全支持
适合企业内网环境

🍎 Mac Native

虚拟接口 + 路由组合
物理接口优先级高于虚拟接口
⚠️ DNS强制走虚拟接口
DNS Relay处理内网域名
不支持流量返回OS
路由规则基于接口优先级

🤖 Android Native

基于VPN Service API
APP Filter + IP Filter 双重过滤
✗ 不支持Exclusive IP
APP级别DNS控制
虚拟接口对未配置APP不可见
精细化应用流量控制

📱 iOS / Mac IPSec

✗ 不支持IP Filter
所有流量进入隧道
无法精细控制分流
依赖系统IPSec实现
配置简单但功能受限

五、实现差异根本原因分析

核心结论：底层引流机制不同导致分流逻辑差异 ┌─────────────────────────────────────────────────────────────┐ │ 1. 支持流量返回OS的平台 (Windows Native) │ │ ├─ 可以精确控制流量进出 │ │ ├─ Exclusive优先级高于Inclusive │ │ ├─ 内网DNS完全支持 │ │ └─ WFP提供了完整的网络堆栈控制能力 │ ├─────────────────────────────────────────────────────────────┤ │ 2. 不支持流量返回OS的平台 (Mac, Android) │ │ ├─ 流量一旦进入虚拟接口/隧道就无法返回 │ │ ├─ 需要在进入前就做好过滤 │ │ ├─ DNS处理机制各有特色 │ │ └─ 依赖操作系统的VPN/TUN接口限制 │ ├─────────────────────────────────────────────────────────────┤ │ 3. 基于路由的实现 (Mac) │ │ ├─ 受系统路由规则限制 │ │ ├─ 接口优先级决定行为 │ │ ├─ DNS强制走虚拟接口导致特殊行为 │ │ └─ 利用DNS Relay机制解决内网域名问题 │ ├─────────────────────────────────────────────────────────────┤ │ 4. 特殊限制平台 (Android) │ │ ├─ VPN Service API限制 │ │ ├─ APP级别控制是独特优势 │ │ ├─ 不支持Exclusive IP是最大限制 │ │ └─ 双重过滤（APP+IP）提供精细控制 │ ├─────────────────────────────────────────────────────────────┤ │ 5. 不支持Filter的平台 (iOS/Mac IPSec) │ │ ├─ 系统IPSec实现限制 │ │ ├─ 只能全流量加速 │ │ └─ 适合简单场景使用 │ └─────────────────────────────────────────────────────────────┘

六、技术术语说明

术语	说明
DP	Data Path - 数据路径处理模块，负责流量加速和处理
POP	Point of Presence - 接入点，进行流量加速的服务器节点
WFP	Windows Filtering Platform - Windows平台的网络过滤框架，提供完整的数据包处理能力
Inclusive	包含列表（白名单），在列表中的IP会被引入DP处理
Exclusive	排除列表（黑名单），在列表中的IP不会被引入DP，走OS转发
ipSetMode	IP集合模式：0=双重配置（Inclusive+Exclusive），1=仅Inclusive
DNS Relay	DNS中继，将DNS请求转发到其他DNS服务器，用于解决内网DNS问题
VPN Service	Android系统提供的VPN服务API，用于创建虚拟网络接口
TUN接口	虚拟网络接口，工作在网络层，用于流量拦截和转发
nfqueue	Linux netfilter队列，用于将数据包传递给用户空间程序处理

📄 文档生成时间:

基于原始技术文档整理分析

⚡ 本文档包含交互式流程图，建议使用现代浏览器查看
支持的浏览器：Chrome 90+, Firefox 88+, Safari 14+, Edge 90+

🔀 IP Filter 分流逻辑对比分析