网关模式下，对两台设备访问同样网站的处理规则行为不一致！

ouzycn

请问一下，同样的Ruleset，什么原因会造成两个同为DHCP（非Surge的DHCP）客户端（一个PC，一个iOS），访问OpenAI.com的规则匹配预期不一样？

这个是PC，不符合预期。，直奔兜底FINAL策略了。

Rule Evaluating - 9 ms
Establishing TCP Connection - 15 ms
Active - 124 s

Events
16:14:33.340290 [Connection] Handled by RDR engine
16:14:33.340513 [TLS] TLS Client Hello SNI: openai.com
16:14:33.350202 [Rule] Rule matched: FINAL
16:14:33.350358 [Rule] Policy decision path: HK -> [ABC] 香港-02
16:14:33.351669 [Socket] Use the last successful address: 183.2.215.168
16:14:33.352102 [Socket] Connecting with address: 183.2.215.168, bound to the primary interface (en0) explicitly under Enhanced Mode, use TCP Fast Open
16:14:33.367463 [Socket] Connected to address 183.2.215.168 in 15ms
16:14:33.367602 [Socket] Attempted to use TCP Fast Open but failed (tfo_heuristics_disable)
16:14:33.367843 [Connector] TCP connection established
16:14:33.383937 [TLS] Proxy TLS handshake completed, negotiated cipher: TLS_AES_128_GCM_SHA256, protocol TLSv1.3
16:16:38.252164 [Connection] Remote closed read stream (Half-closed)
16:16:38.253173 [Connection] Disconnect with reason: Closed by remote

这个是iOS，规则匹配符合预期，我的OpenAI.list优先级仅次于其它必须在其前面的，不管怎么都应该在FINAL兜底之前。

Rule Evaluating - 5 ms
Establishing TCP Connection - 15 ms
Active - 270 ms

Events
16:26:32.273019 [Connection] Handled by RDR engine
16:26:32.273302 [TLS] TLS Client Hello SNI: ios.chat.openai.com
16:26:32.278765 [Rule] Sub-rule matched: DOMAIN-KEYWORD openai(OpenAI.list)
16:26:32.278844 [Rule] Rule matched: RULE-SET OpenAI.list
16:26:32.279034 [Rule] Policy decision path: OpenAI -> Media -> HK -> [ABC] 香港-02
16:26:32.280906 [Socket] Use the last successful address: 183.2.215.168
16:26:32.281434 [Socket] Connecting with address: 183.2.215.168, bound to the primary interface (en0) explicitly under Enhanced Mode, use TCP Fast Open
16:26:32.297045 [Socket] Connected to address 183.2.215.168 in 15ms
16:26:32.297138 [Socket] Attempted to use TCP Fast Open but failed (tfo_heuristics_disable)
16:26:32.297354 [Connector] TCP connection established
16:26:32.313386 [TLS] Proxy TLS handshake completed, negotiated cipher: TLS_AES_128_GCM_SHA256, protocol TLSv1.3
16:26:32.584475 [Connection] Disconnect with reason: Closed by client

ruleset: OpenAI.list

# NAME: OpenAI
# AUTHOR: blackmatrix7
# REPO: https://github.com/blackmatrix7/ios_rule_script
# UPDATED: 2023-10-28 02:15:45
# DOMAIN: 1
# DOMAIN-KEYWORD: 1
# DOMAIN-SUFFIX: 12
# TOTAL: 14
DOMAIN,ai.cn
DOMAIN-SUFFIX,ai.com
DOMAIN-SUFFIX,auth0.com
DOMAIN-SUFFIX,challenges.cloudflare.com
DOMAIN-SUFFIX,client-api.arkoselabs.com
DOMAIN-SUFFIX,events.statsigapi.net
DOMAIN-SUFFIX,featuregates.org
DOMAIN-SUFFIX,identrust.com
DOMAIN-SUFFIX,intercom.io
DOMAIN-SUFFIX,intercomcdn.com
DOMAIN-SUFFIX,poe.com
DOMAIN-SUFFIX,sentry.io
DOMAIN-SUFFIX,stripe.com
DOMAIN-KEYWORD,openai

mieqq

你看看你PC的请求是不是ip加域名的形式，例如 1.1.1.1 (cloudflare.com)。这种情况是没接管到DNS请求，域名规则不会生效，除非开了 extended-matching

ouzycn

mieqq
谢谢回复，但是「IP 加域名的形式」没看懂什么意思，在 PC 是正常浏览器打开 openai.com以及登录，在 iOS 是 ChatGPT app 打开的，而你说的情况是怎样的场景呢？
另外，「extended-matching」应该加到哪里呢？

mieqq

ouzycn 就是看Surge最近请求或dashboard里的域名，是不是这样显示，1.1.1.1 (cloudflare.com)

ouzycn

mieqq
并不会像你举例的那样，而是正常的
ID,日期,客户端,状态,策略,上传,下载,时长,方法,地址
171945,下午8:45:57,192.168.1.190:7732,已完成,[BosLife] 香港-02 (RULE-SET OpenAI.list),517 B,0 B,1048 ms,HTTPS,images.openai.com:443

另外，翻到了

协议嗅探
发往 80 与 443 端口的请求，会等待客户端发送第一个数据包后，提取 SNI 等信息用于规则系统判断。
DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD 规则新增可选参数 extended-matching。开启该参数后，该规则将同时尝试匹配 SNI 和 HTTP Host Header （或 :authority）中的字段。

btw, Surge for Mac 5.40 (2470)

mieqq

ouzycn 看你PC的请求，不符合预期的，你上面请求明显匹配中了相应的规则集

ouzycn

mieqq
Rule matched: FINAL
这是规则的最后一条，兜底的，意味着前面 ruleset: OpenAI.list 并没用命中，，，

mieqq

ouzycn

哎，这里聊太难了，也没个图。反正就两个可能，一是规则集没加载好，可以通过外部资源查看，二是没接管到你PC的DNS，导致域名规则没匹配到，你可以查看dashboard地址是不是显示ip(域名）来检查。

ouzycn

吃过饭，回来更新修订了。
如果大量的 1.2.3/4 (a.b.c.d) 记录，且客户机打开openai.com的时候，在从Surge Dashboard

不在出现
Ruleset处理符合

那么，我认为当前的问题就是已经解决了。

我的排查方法：

基于Surge Dashboard出现如下的信息，且留意到占比最大的是208.67.222.222:53，且是UDP方式

13.107.6.163:443 (upload.fp.measure.office.com)
208.67.222.222:53 (Port Map)
52.123.178.65:3478 (Port Map)

208.67.222.222:53 (Port Map)
Rule Evaluating - 10 ms
Active - 67 s

Events
17:25:53.667106 [Rule] Rule matched: FINAL
17:25:53.667268 [Rule] Policy decision path: HK -> [BosLife] 香港-02
17:25:53.667500 [UDP] Working in Port Map mode. The client might send and receive data from multiple IP addresses.
17:27:00.837451 [UDP] Closed for inactivity.

因此，在ip-api.com 查询发现是：

{
    "query": "208.67.222.222",
    "status": "success",
    "continent": "North America",
    "continentCode": "NA",
    "country": "United States",
    "countryCode": "US",
    "region": "MO",
    "regionName": "Missouri",
    "city": "Wright City",
    "district": "",
    "zip": "63390",
    "lat": 38.811,
    "lon": -91.0332,
    "timezone": "America/Chicago",
    "offset": -21600,
    "currency": "USD",
    "isp": "Cisco OpenDNS, LLC",
    "org": "Cisco OpenDNS, LLC",
    "as": "AS36692 Cisco OpenDNS, LLC",
    "asname": "OPENDNS",
    "mobile": false,
    "proxy": false,
    "hosting": false
}

然后，查客户机本地的情况， ipconfig/all 并无异常

Wireless LAN adapter Wi-Fi:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Intel(R) Wi-Fi 6 AX201 160MHz
   Physical Address. . . . . . . . . : 08-5B-XXXXXXX-FF-50-B9
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 192.168.1.160(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : 2023年11月17日 15:05:31
   Lease Expires . . . . . . . . . . : 2023年11月18日 15:05:31
   Default Gateway . . . . . . . . . : 192.168.1.200
   DHCP Server . . . . . . . . . . . : 192.168.1.253
   DNS Servers . . . . . . . . . . . : 198.18.0.2
   NetBIOS over Tcpip. . . . . . . . : Enabled

并且，nslookup 也显示DNS就是Surge的DNS

C:\Users\ooo>nslookup
Default Server:  UnKnown
Address:  198.18.0.2

既然，上述出现了208.67.222.222:53 Cisco OpenDNS

因此，试着 Netstat -a 发现 127.0.0.1:53 有启用，初步判断，是不是本地DNS被劫持了。

然后在 Task manager - service 搜索 DNS 发现有个dnscrypt-proxy （Cisco AnyConnect Secure Mobility Agent for Windows）
那就去 Service 控制面板查到这个服务， Stop 这个服务。

结果：

127.0.0.1:53 不再出现
Surge Dashboard 不再出现 大量的 1.2.3/4 (a.b.c.d) 这种记录

但依然有少量183.61.169.210:443 (Port Map)记录
继续观察中。。。