V2ray-core: [feature request] 增加 Fake IP / Fake DNS 功能

[EqCScO9nTa]

未解决的问题

在透明代理模式下，被代理的程序将会自行发送出 DNS 请求。目前，用户可以将 DNS 请求转发到代理进行处理（直接发出或经过代理服务器发出）。
对于受 DNS 污染影响的域名，用户必须将 DNS 请求发送至服务器来获取正确的 IP 地址，而这在访问网站之前需要消耗 1RTT。

什么是 Fake IP

当用户发送 DNS 请求时，代理并不发送请求到远程 DNS 服务器，而是为每个域名返回一个唯一假 IP。在指向这些假 IP 的流量发送到代理时，按查询得到的域名重置当前连接的目标。

目前的方案及它们的局限

Socks 5 或 HTTP 代理方式

程序会将域名直接发送至对于 Socks 5 或 HTTP 代理 ，在服务端进行解析。
手动为程序配置代理需要消耗大量的精力，并且对于不支持这些代理方式的程序 / 平台，这种方式是不友好的。

V2Ray 已有的 Sniffing 方案

参见已有的讨论。大概思路是用本地 DNS 服务器给所有需要代理的域名返回同一个不可访问的 IP，之后在流量再次发送到 V2Ray 时，按流量中包括的目标地址重置当前连接的目标，从而达到不需要访问远程 DNS 服务器的效果。而且，在 V2Ray 支持本地 DNS 处理之后，可以直接在 Hosts 规则里面拦截这些请求。
这个方案会污染本地 DNS 缓存。同时最大的问题在于，Sniffing 功能只能从 HTTP / TLS 类型的流量中提取出域名，而考虑到我们使用的是一个虚假的 IP，这将直接导致部分功能不可用（UDP 全崩）。

额外的 Fake IP 程序

参考 go-tun2socks，仅有少数的 GUI 程序支持该项目与 V2Ray 同时使用，目前发现两个：kitsunebi, mellow. 它们直接修改了 V2Ray 内核，与 go-tun2socks 均来自同一开发者。
手动部署 go-tun2socks 将（较大幅度）增加用户使用 V2Ray 的成本。

Fake IP 的代价

返回错误的 IP 会污染本地 DNS 缓存，使得代理断开之后一段时间内设备无法访问网络。

[EqCScO9nTa]

我会尝试着为 V2Ray 加入这项功能，请各位尝试目前的可用版本并提供意见。
我希望能实现仅为指定的域名实现 Fake IP，同时能指定 Fake IP 的范围。

[kslr]

我希望能实现仅为指定的域名实现 Fake IP，同时能指定 Fake IP 的范围。

这个是怎么考虑的，我的想法是如果能替换掉Sniffing的实现也挺好的

[Cwek]

我也觉得这个想法很好。
Fake IP的范围可以考虑指定用v4分类地址E组（240.0.0.0~247.255.255.255）或者v6唯一区域位域（fc00::/7）。Fake IP作为一个独立大模块，在inbound上配置启用（相当于挂在一个处理入口），然后inbound在检测到域名访问（包括socks5等的域名请求连接，或者Sniffing到dns的请求）时分配域名与地址的映射，然后inbound收到Fake IP的地址连接访问时，反向找回域名，转为域名连接访问。

[EqCScO9nTa]

我的想法是如果能替换掉Sniffing的实现也挺好的

在inbound上配置启用（相当于挂在一个处理入口），然后inbound在检测到域名访问（包括socks5等的域名请求连接，或者Sniffing到dns的请求）时分配域名与地址的映射

我目前的方案是为 V2Ray 的 DNS 配置中加入一个 useFake 数组与一个 fakeNet，里面包含一组域名以及一个 IP 带子网掩码，分别表示需要启用 Fake IP 的域名以及 Fake IP 的生成域。当符合条件的请求发送到 DNS 服务器时，为其返回一个生成域中的 Fake IP 并储存域名与 IP 的映射。之后在 Dispatcher 模块（Sniffing 处理的地方）加入对 IP 的判断，如果能在映射表里为这个 IP 找到对应的域名，就用这个域名替换掉流量的目标地址。

我认为将该功能作为本地 DNS 服务器的增强比作为 Inbound 的增强更为合理。如果要在 Inbound 处拦截 DNS 流量的话，需要额外添加检测步骤（检测发往 53 与 853 端口的流量？），这在增加了代码量的同时也降低了处理效率。

[forever8938]

如果用fake ip, 某些浏览器会打不开某些网页，最典型的就是safari浏览器无法播放油管视频，有人知道为什么吗？

[EqCScO9nTa]

某些浏览器会打不开某些网页，最典型的就是safari浏览器无法播放油管视频

我刚刚测试了一下我的 Fake IP 实现对于 UDP 流量是正常工作的。

能具体描述一下你的使用场景 / 遇到的问题吗？

[forever8938]

@EqCScO9nTa 使用场景是路由器透明代理。

在dnsmasq的配置文件里把gfwlist域名解析到1.2.3.4，

address=/google.com/1.2.3.4

然后redirect到v2ray的透明代理端口，v2ray打开sniffing。

iptables -t nat -A v2ray -d 1.2.3.4 -p tcp --dport 80 -j REDIRECT --to-ports 12345
iptables -t nat -A v2ray -d 1.2.3.4 -p tcp --dport 443 -j REDIRECT --to-ports 12345

直连路由器的情况下：

• ios和mac的safari不能播放油管视频，控制台显示无法加载googlevideo.com。其他网站没发现问题。
  
  

• ios的chrome和firefox问题同上。
• ios的油管app正常
• Android的firefox连谷歌主页都打不开（证实是国产手机的问题）
• windows和mac上的chrome和firefox正常
• 如果不使用fakeip，直接向公网查询，则没有以上问题，各种浏览器都可以正常工作。

[ix64]

@EqCScO9nTa 使用场景是路由器透明代理。在dnsmasq的配置文件里把gfwlist域名解析到1.2.3.4，然后把TCP的80和443端口redirect到v2ray的透明代理端口，v2ray打开sniffing。

直连路由器的情况下：

• ios和mac的safari不能播放油管视频，控制台显示无法加载googlevideo.com。其他网站没发现问题。

• ios的chrome和firefox问题同上。
• ios的油管app正常
• 安卓的Firefox则连谷歌主页都打不开
• windows和mac上的chrome和firefox正常
• 如果不对dnsmasq做任何处理，就让墙污染，则没有以上问题，各种浏览器都可以正常工作。

Console的错误提示，看起来只是CORS标头的问题，传输是没有出错的。

[EqCScO9nTa]

在dnsmasq的配置文件里把gfwlist域名解析到1.2.3.4

我尝试着用 V2Ray 的 DNS hosts 复现你的配置，将 YouTube 的 IP 解析为 1.2.3.4。Sniffing 功能在 TCP 流量上正确启用（在 UDP 流量上则是直接把数据发到了 1.2.3.4

• 安卓的Firefox则连谷歌主页都打不开

Android 端 Chrome 和 Google App 访问 Google 与 YouTube 正常。

• windows和mac上的chrome和firefox正常
• ios和mac的safari不能播放油管视频，控制台显示无法加载googlevideo.com。其他网站没发现问题

Linux 下 Chrome 工作正常，Google 和 YouTube 正常打开。

目前见到的（除 DNS 请求外的） UDP 流量都是发往 443 端口的，应该是建立 QUIC 连接的请求，所以就算发到了错误的 IP 也没有影响到使用 TCP 连接浏览网页。

[forever8938]

• 安卓的Firefox则连谷歌主页都打不开

Android 端 Chrome 和 Google App 访问 Google 与 YouTube 正常。

这个应该是我的手机问题，我就不测了。我的一台小米手机无论如何都打不开。
safari的问题，我很早就知道了，不会搞错的。

[kingwilliam]

纯技术探讨, 在透明代理系统内加入 dns cache 是否也类似fake ip成效?

• 目的是减少dns流过 v2ray tunnel 引至延迟
• 在客户端dns cache回覆也可和提速
  
• 在第一次dns request, 用了36msec, 因真的要问远方dns取所需ip.
• 在第二次request同一host, 只用了1msec, 因在客户端dns cache已有所需ip,可以直接回覆.

[EqCScO9nTa]

在透明代理系统内加入 dns cache 是否也类似fake ip成效

1. DNS cache 确实可以提高二次访问同一域名时的查询速度。
2. 当前 V2Ray 中已实现 DNS cache 。
3. 在请求新的域名时 DNS cache 无能为力，同时因为 DNS 查询到的 IP 具有时效，一个域名的 DNS cache 必须在一段时间之后的下一次访问时更新，而 Fake IP 则无此限制。

[forever8938]

@EqCScO9nTa 我编译了你的代码，请问配置文件怎么写？

[EqCScO9nTa]

配置文件怎么写？

"dns" {
  "fake": {
    "fakeRules": ["geosite:cn"],
    "fakeNet": "224.0.0.0/8"
  }
}

类似这样，具体意思在上面。

[forever8938]

@EqCScO9nTa 我试了一下觉得挺好的，之前打不开的网页都能打开了。

似乎不支持匹配所有域名。当fakeRules对象不存在时，不匹配任何域名，相当于禁用。这里希望改成当fakeRules对象不存在时，匹配所有域名。要禁用的话只要fake对象不存在就行了。

[EqCScO9nTa]

似乎不支持匹配所有域名。

因为重构之后和 Hosts 使用的是同一套匹配系统，所以可以直接用正则表达式
"regexp:.*"

希望改成当fakeRules对象不存在时，匹配所有域名。要禁用的话只要fake对象不存在就行了。

所以这样做没有必要，并且我个人认为没有规则存在时匹配所有违反直觉。

[forever8938]

在路由模块，如果一条规则没有domain/ip的条件，就是所有domain/ip都可以。有时候需要在最后匹配上所有流量，我自然想到一条匹配所有流量的规则就是什么条件都没有。不过现状是至少要有一个条件，否则报错。所以fakeRules不存在时，如果不匹配所有域名，建议报错。

[EqCScO9nTa]

在路由模块，如果一条规则没有domain/ip的条件，就是所有domain/ip都可以。

唔... 如果有除了 Domain / IP 的其它条件存在的话确实如此。

有时候需要在最后匹配上所有流量，我自然想到一条匹配所有流量的规则就是什么条件都没有。不过现状是至少要有一个条件，否则报错。所以fakeRules不存在时，如果不匹配所有流量，建议报错。

我考虑一下哪种比较好，你认为报错还是全部接受合理？

[forever8938]

你认为报错还是全部接受合理？

报错吧。

[Dreamacro]

fakeip 的问题在于过期时间，从实际使用来看（我的软件），大多数应用不遵守 dns 的 ttl，无论是正常的 ttl 还是 ttl 为 1，都存在着应用不遵守 fakeip ttl 的情况，应用会在 ttl 后继续使用 fakeip 但应用里不存在对应的反映射，造成连接问题，我的解法是存一个适当长度的 lru cache，只在超出 size 的时候踢出缓存。第二个在于 fakeip 是否需要持久化，如果我为了某个配置而重新启动程序，那么之前应用内所拿到的 fakeip 都将失效。

[EqCScO9nTa]

报错吧。

已在 commit 5de5b9b 添加。

[EqCScO9nTa]

应用会在 ttl 后继续使用 fakeip 但应用里不存在对应的反映射，造成连接问题

我现在的做法是不丢弃 Fake IP，而是储存所有已经被分配过的 Fake IP - 域名映射，在数量达到上限之后停用 Fake IP 功能。不过考虑到这样会消耗大量的内存（以及找查映射的时间问题），环形数组似乎确实是更优的方案。

fakeip 是否需要持久化

V2Ray 除了日志之外应该没有其它的写入文件操作，我倾向于默认不在程序关闭之后保存 Fake IP ，做成可选项。

[Dreamacro]

@EqCScO9nTa 环形数组和 lru 概念是不一样的，lru 更倾向于保留「热」数据，而环形数组更像是一个限制长度的缓存。我吃了很多不持久化的亏，导致每次重启时都得等好一段时间才能正常使用，不过不保存也有不保存的好处，不需要考虑缓存错误带来的域名错位问题。

[ToutyRater]

支持！过了这么久终于有人做这个功能了。
我不清楚代码怎么写的，只是从使用者的角度提个需要留意的地方，像下面的配置，freedom 的 domainStrategy 如果指定了 UseIP | UseIPv4 | UseIPv6，这个时候 freedom 会使用 V2Ray 的 DNS 模块，这时候应该注意返回真实的 IP，而不是 Fake IP。

{
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "UseIP" 
      }
}

[EqCScO9nTa]

环形数组和 lru 概念是不一样的，lru 更倾向于保留「热」数据

明白了，这样比起全部存下来是个性能更高的方案。我觉得可以默认使用 LRU，用户根据需求可选全存。

freedom 的 domainStrategy 如果指定了 UseIP | UseIPv4 | UseIPv6，这个时候 freedom 会使用 V2Ray 的 DNS 模块，这时候应该注意返回真实的 IP，而不是 Fake IP。

这个问题确实存在，但是我需要具体研究一下怎么实现。

[daiaji]

干脆整个检测到dns污染，则自动代理被污染域名的功能如何？
现在被墙网站几乎都被dns污染在先了吧。
这样不用配置被墙网址列表，如果能输出列表，那最好。

[ToutyRater]

@daiaji

干脆整个检测到dns污染，则自动代理被污染域名的功能如何？

1. 我想知道该用什么手段来检测一个域名 DNS 是否受到污染；
2. 虽然无法检测是否污染，但是目前 V2Ray 已经能够通过 DNS 分流解决污染问题；
3. 我认为 Fake IP 更重要的意义在于解决远程 DNS 多消耗的一个 RTT 以及准确获知目标地址域名。

[EqCScO9nTa]

现在被墙网站几乎都被dns污染在先了吧。

需要通过代理的网站并不一定完全不能访问，类似 GitHub ，DNS 会返回正确的 IP 地址。

Fake IP 更重要的意义在于解决远程 DNS 多消耗的一个 RTT 以及准确获知目标地址域名。

我的看法也是如此。Fake IP 比起 Sniffing 的优势是在 HTTP 或 TLS 协议外也能准确获知目标域名。

[ToutyRater]

似乎还有一个问题，如果指定 routing 的 domainStrategy 为 IPIfNonMatch | IPOnDemand，由于使用了 Fake IP 功能，Dispatcher 模块根据 Fake IP 将目标地址重置为域名，当没有匹配的域名规则时，就会查询该域名的 IP。这个时候 DNS 该怎么处理，是返回 Fake IP 还是真实 IP？如果是 Fake IP，就有可能应用的规则不是想要的；如果是真实的 IP，还是会额外消耗一个 RTT。我认为还是返回真实的 IP 较好，慢总比错好。

[EqCScO9nTa]

指定 routing 的 domainStrategy 为 IPIfNonMatch | IPOnDemand，返回 Fake IP 还是真实 IP？

呃

我认为继续返回 Fake IP 更为合适。用户已经在规则里面指定了哪些域名需要 Fake IP 处理，这直接表明了用户希望以域名规则来在远端处理它的意愿。与 Freedom outbound 的 UseIP 中用户明确希望以 IP 连接不同，

如果希望对某个域名以请求回来的 IP 匹配路由规则的话，更好的做法应该是用户在 Fake IP 规则里面排除该域名，而不是再查询一次（这会直接导致只要路由规则中只要出现一个使用 IP 的规则，Fake IP 功能直接失去意义）。

[ToutyRater]

用户已经在规则里面指定了哪些域名需要 Fake IP 处理，这直接表明了用户希望以域名规则来在远端处理它的意愿。

想了想，是这个理。

[GEM7]

首先感谢您的commit！

Fake IP / Fake DNS 这个功能和 Surge for Mac 的增强模式 非常类似，在实际使用中都有不错的效果，并且在规则中对指定域名使用 Fake DNS 可以最大限度避免污染其他域名的 DNS 缓存，代价其实不算大。

起因

我最近在Sniffing上出了点问题，想讨教一下 sniffing 作用的细节，在issue 24中，提到了如下细节：

@ToutyRater 你说的这个构想其实v2ray 早就实现了，那就是 destOverride, 我一直是这么用的:
配合dnsmasq 设置主dns server 为国内dns server，其他将所有gfwlist域名解析到1.2.3.4这个伪造ip：
server=114.114.114.114 #非污染域名解析
address=/google.com/1.2.3.4 #污染域名解析
address=/twitter.com/1.2.3.4
.......
然后iptable 转发所有目标地址为 1.2.3.4 的数据包到 透明代理-> v2ray inbound dokodemo-door, 开启destOverride，这样就重置了http(s)链接的dest domain，再通过outbound发送到vps，实现了远端dns解析和数据访问。
这样就实现了域名分流。用了近半年了，相当可靠。
这样的配置很精简，不需要设置dns和routing，v2ray仅对污染域名全部转发。巧妙的利用构造虚假ip地址，实现了iptable类似域名分流的功能。也比v2ray应用层实现分流更可靠，即使是v2ray 客户端或vps服务出现故障不能访问，也不会影响非污染域名的网站访问。

Sniffing 功能嗅探到域名后的这个

重置了http(s)链接的dest domain

该理解比较合适？对于上述描述，我的理解是这样的：iptables 把送往假IP的 流量直接转到 inbound => inbound收到了真域名和假IP=>Sniffing嗅探出域名=>把域名送进Routing=>Routing 判断这个域名走 Proxy => 然后在远程服务器收到域名，解析，访问。

所以, 抛开上述场景。Sniffing 的功能单独来看相当于无论这个IP正确，把IP弃掉，一律把IP弃掉，把域名直接送进Routing。那"重置"就是弃掉之间的解析结果，相当于重新用域名做连接。不知道我的理解对不对。

我尝试理解原理。

Sniffing

首先，我使用了 V2ray 内置的 DNS 分流功能：

  "dns": {
    "servers": [
      "8.8.8.8",
      {
        "address":"114.114.114.114",
        "port":53,
        "domains":[
          "geosite:cn"
        ],
        "expectIPs":[
          "geoip:cn"
        ]
      }
    ]
  },

以下是outbounds部分：

  "outbounds": [
    {
      "protocol": "socks",
      "tag": "Proxy",
      "settings": {
        "servers":[
            {
                "address":"127.0.0.1",
                "port":1080
            }
        ]
      }
    },
    {
      "protocol": "freedom",
      "settings": {
       "domainStrategy": "UseIP"
     },
      "tag": "Direct"
    },
    {
      "protocol": "dns",
      "tag": "Dns-Out",
      "settings": {}
    }

然后，开启了DNS Outbound，并把所有DNS流量送入DNS Outbound, 这样根据描述，DNS Outbound 会拦截请求，通过内置 DNS 得到结果，再把结果送回请求方。请求方得到了返回结果；请求方向返回的IP地址发起链接，这部分流量被送入inbound。此时 Routing 匹配该 IP。直连则送Freedom，否则将其以送到Proxy访问IP。

如果我们打开了Sniffing，那么上述过程会发生变化。

请求方向返回的地址发起链接，被送入inbound，Sniffing 嗅探出域名。Routing 根据域名进行匹配，如果直接连接则直接使用内置 DNS 解析出IP,出Freedom；如果走代理则送到代理去解析访问。

就是说开启了 Sniffing 在Routing部分带来的变化就是：

| 不开 Sniffing | 开 Sniffing |
| :-: | :-: |
| Routing 匹配的是 IP | Routing 匹配的是域名 |

对于DNS查询来说，带来了以下变化：

| | 不开 Sniffing | 开 Sniffing |
| :-: | :-: | :-: |
| 查询次数 | 1次 | 3次 |
| 查询位置 | DNS Outbound 1次| DNS Outbound 1次，Sniffing 后在内置DNS 1次，Freedom Outbound UseIP 时内置DNS再查1次 |

FakeIP / FakeDNS

同样地，对于FakeIP / FakeDNS，我理解的流程如下（对墙外域名使用FakeIP）：

应用发起请求，DNS Outbound 会拦截请求，因为开启了Fake IP，所以通过内置 DNS 得到了Fake IP
。再把结果送回请求方。请求方得到了返回结果；请求方向Fake IP地址发起链接，这部分流量被送入inbound，检测该IP是Fake IP。于是查询 Domain-FakeIP 表，得到域名，把域名送入Proxy，远程解析，访问。
而墙内网站直接通过DNS Outbound 得到正确IP，Routing 到 Freedom Outbound。

在 Routing 方面：

| 未设FakeIP的域名 | 设FakeIP的域名 |
| :-: | :-: |
| Routing 匹配的是 IP | Routing 匹配的是域名 |

对于DNS查询来说，带来了以下变化：

对于墙内域名

| | 不开 Fake IP | 开 Fake IP |
| :-: | :-: | :-: |
| DNS查询次数 | 1次 | 2次 |
| 查询位置 | DNS Outbound 1次| DNS Outbound 1次（Fake)， Freedom Outbound UseIP 时内置DNS再查1次 |

对于墙外域名
| | 不开 Fake IP | 开Fake IP |
| :-: | :-: | :-: |
| DNS 查询次数 | 1次 | 2次 |
| 查询位置 | DNS Outbound 1次| DNS Outbound 1次（Fake)， Proxy远程查1次 |

P.S. 这样看来，有了FakeDNS，V2ray的内置DNS可以不配置8.8.8.8了👍。

所以，在开启了 V2ray 内置DNS分流功能的情况下：

| | Fake IP / Fake DNS | Sniffing |
| :-: | :-: | :-: |
| 墙内域名 | 1次 | 1 次 |
| 墙外域名 | 2次 | 3次 |

以上是我的浅见，不知道我对Sniffing, FakeIP / FakeDNS 作用机理的理解以及 Routing阶段 判断的对象和执行过程是否描述的准确。

[EqCScO9nTa]

这个时候 freedom 会使用 V2Ray 的 DNS 模块，这时候应该注意返回真实的 IP，而不是 Fake IP。

commit 7b3d995

[EqCScO9nTa]

| | 不开 Sniffing | 开 Sniffing |
| :----------: | :---------------: | :------------: |
| 查询次数 | 1次 | 3次 |
| 查询位置 | DNS Outbound 1次 | DNS Outbound 1次，Sniffing 后在内置DNS 1次，Freedom Outbound UseIP 时内置DNS再查1次|

我认为这里开启 Sniffing 之后总共只需要查询两次 DNS，分别为 DNS Outbound 一次，Freedom Outbound 一次。

所以应该是

| | Fake IP / Fake DNS | Sniffing |
| :----------: | :-------------------------: | :--------: |
| 墙内域名 | 1次 | 1次 |
| 墙外域名 | 2次 | 2次 |

但是查询次数没什么意义，因为结果会被缓存。更重要的是按照你的配置的话，会出现是否向 DNS 服务器进行查询的区别

| | Fake IP / Fake DNS | Sniffing |
| :----------: | :-------------------------: | :--------: |
| 墙内域名 | 是 | 是 |
| 墙外域名 | 否 | 是 |

[GEM7]

我认为这里开启 Sniffing 之后总共只需要查询两次 DNS，分别为 DNS Outbound 一次，Freedom Outbound 一次。

你好，感谢你的回答。是我欠考虑了，情况描述的不太准确。我考虑到三次的原因是因为Routing 默认的策略IPIfNonMatch的关系。

对于国外域名：

如果这个策略，那么在 DNS Outbound (第1次)之后，流量被Sniffing 嗅探出域名，然后丢进Routing，在只直连私有IP和中国域名/ IP这样的Routing 设置下。外国域名首先被进行域名匹配，域名匹配不到，根据IPIfNonMatch的机制利用内置DNS 解析出IP(第2次) 再利用 IP 匹配，外国IP也不在范围，故送到Proxy 远程解析（第三次）

而对于国内域名

DNS Outbound (第1次)，流量被Sniffing 嗅探出域名，域名进入Routing，匹配成功，送到Outbound，UseIP机制继续解析一次(第二次)

上述的情况总结一下：

| |不开Sniffing | 开启Sniffing |
|:-:|:-:|:-:|
|国内域名| 1次 | 2次 |
|国外域名| 1次 | 3次 |

这样应该是合理的

[EqCScO9nTa]

在 IPIfNonMatch 策略下应该和你描述的一样。

我考虑到三次的原因是因为Routing 默认的策略IPIfNonMatch的关系。

域名解析策略，根据不同的设置使用不同的策略。

• "AsIs": 只使用域名进行路由选择。默认值。

[GEM7]

AsIs": 只使用域名进行路由选择。默认值。

这样的话就明白了，'AsIs' 是只匹配域名，匹配不到直接送默认Outbound（一般为第一个）

P.S. 乍一看 IPOnDemand 是遍历次数最少的，域名进入Routing，匹配时碰到任何基于 IP 的规则，将域名立即解析为 IP 进行匹配，相当于走一遍Routing表一定会有个结果。但，根据这个描述，Routing 如果是域名和IP规则交替出现，那效率就要大大降低。如此说来对Routing规则，不能“域名规则”，“IP规则交替出现”。

[klzgrad]

几个建议：

1. 根据https://www.ctrl.blog/entry/dns-client-ttl.html 一般应用的最小ttl是一分钟，但是chrome系的浏览器有一个功能叫“检测网络变化”，例如打开关闭vpn的时候会把dns缓存清空。
2. 保存假ip是一个严重的隐私问题，等于保存浏览记录。

[EqCScO9nTa]

保存假ip是一个严重的隐私问题，等于保存浏览记录。

这确实是一个问题，所以就算要实现永久化储存 Fake IP 的功能也会是可选项并默认关闭。

不过想要保存浏览记录的话直接开 Log 更方便一些。

[ToutyRater]

@klzgrad

保存假ip是一个严重的隐私问题，等于保存浏览记录。

观察点不错，但我不是很认同。

1. @EqCScO9nTa 说了将提供开关选项
2. 哪怕没有开关，使用 Fake IP 与否是用户行为
3. 如果说隐私，比起存假 IP 更敏感的是 Log，毕竟 Fake IP 功能存假 IP 只是域名和 IP 的映射，log 还有更具体的时间等其他信息
4. 这些文件是用户可控、可任意处理的，除非开发者脑子抽了写代码将 Log 等敏感信息上传到某些服务器
5. 比起 V2Ray 本身，我现在更担心国内运营商和互联网企业方面的隐私措施

[klzgrad]

说用户可以关掉没用。

开启这个功能的效用：偶尔重启的时候，更顺滑一点。
开启这个功能的损失：多了一个浏览隐私的记录点。

效用和损失明显不相称。当然如果你觉得隐私无所谓，这也是一种正常的使用方式。

[EqCScO9nTa]

开启这个功能的效用：偶尔重启的时候，更顺滑一点。

没有保存 Fake IP 映射表的话，存在用户在 DNS 缓存失效之前都无法正常使用网络的可能性。这个时间取决于应用程序的实现。

效用和损失明显不相称。

但不可否认，对于关注隐私（并且容易将本地日志泄漏）的用户来说确实如此。这也是为什么这个特性将会默认关闭。

• 对于用户完全控制的客户端，不存在在不知情的情况下保存映射表的场景。
• 对于用户不能完全控制的客户端（例如被修改的闭源二进制包，路由器透明代理），确实可以在用户不知情的情况下窃取隐私。但比起保存映射表，窃取者直接开启记录日志的可能性更具有威胁性，而这是无法避免的。

[klzgrad]

默认关闭是好的，但是想象一下“某VPN软件自带网站访问流量记录功能”从第三方看起来的效果。

[EqCScO9nTa]

想象一下“某VPN软件自带网站访问流量记录功能”从第三方看起来的效果。

呃

大概是 Log 等级设置为 info 的效果。

[kslr]

这并不是这个功能需要考虑的问题，你也许可以试试Tor

[klzgrad]

有一个折中的方案，你可以用memfd或者shm把中间结果保存在内存里，然后做一些权限控制，只要系统不重启，程序本身重启的时候交接一下。总之不要保存到硬盘上。

[mzz2017]

有一个折中的方案，你可以用memfd或者shm把中间结果保存在内存里，然后做一些权限控制，只要系统不重启，程序本身重启的时候交接一下。总之不要保存到硬盘上。

你这么在意隐私问题，v2ray配置文件中还保存着你服务器vmess的密码呢。

[EqCScO9nTa]

可以用memfd或者shm把中间结果保存在内存里，然后做一些权限控制，只要系统不重启，程序本身重启的时候交接一下。总之不要保存到硬盘上。

这应该交由用户设置。可以创建一个位于内存的文件，然后指定为 Fake IP 的储存位置。

[fbion]

提供一种电脑做网关的思路

可以的
https://github.com/FlowerWrong/tun2socks
https://github.com/xjasonlyu/tun2socks
这两个已经实现fake dns
surge增强模式也是这样
有两种方式
google.com -> 192.18.0.1
google.com.hk -> 192.18.0.2

google.com -> 192.18.0.1:1111
google.com.hk -> 192.18.0.2:1112

通过这种关联即可

个人系统192.168.1.2开启
net.inet.ip.forwarding=1
开启tun2socks
sudo route add 198.18.0.2/24 240.0.0.1(tun网关)

手机设置网关192.168.1.2
所有流量走192.168.1.2了吧
192.168.1.2开启fake dns
手机dns服务器也设置为1.2
手机访问google.com 得到ip 192.18.0.1
手机连接192.18.0.1经过192.168.1.2
192.18.0.1走tun接口
tun2socks检测到访问192.18.0.1->google.com

此时tun2socks->v2ray inbounds
由v2ray来识别国外国内 google facebook twitter等域名

假如手机访问baidu,v2ray直接识别为geosite:cn ip 流量直接国内走

tun2socks只需要提供fake dns和代理功能
分流交给v2ray来做
这样

[EqCScO9nTa]

实现 LRU Cache
实现持久化储存

[github-actions[bot]]

This issue is stale because it has been open 120 days with no activity. Remove stale label or comment or this will be closed in 5 days

[Vigilans]

使用Fake DNS后，似乎对UDP流量也可以拿到域名了？目前的Sniffing嗅探域名只对TCP流量（且只有HTTP、TLS）有效。如果可以的话，这个特性似乎对于收集域名，做定制的域名库比较有帮助。

[ToutyRater]

使用Fake DNS后，似乎对UDP流量也可以拿到域名了？目前的Sniffing嗅探域名只对TCP流量（且只有HTTP、TLS）有效。如果可以的话，这个特性似乎对于收集域名，做定制的域名库比较有帮助。

是的，sniffing的缺陷就在此，但这个 fake dns 好久没动静了

[github-actions[bot]]

This issue is stale because it has been open 120 days with no activity. Remove stale label or comment or this will be closed in 5 days