在某台位于 SG 机器上使用的 DNS 服务器是 8.8.8.8 1.1.1.1
最近发现一些域名，比如：（域名前面代表次数 可以忽略）
- 11276 safebrowsing.googleapis.com
- 1199 www.gstatic.com
- 1112 ssl.gstatic.com
- 465 update.googleapis.com
- 409 fonts.googleapis.com
- 377 fonts.gstatic.com
- 232 clientservices.googleapis.com
- 109 googleads.g.doubleclick-cn.net
- 87 www.googletagmanager.com
- 73 www.google-analytics.com
- 66 connectivitycheck.gstatic.com
- 38 www.googleadservices.com
- 37 redirector.googlevideo.com
通过 8.8.8.8 解析，拿到的结果是 CN 的； 通过 1.1.1.1 解析，拿到的就都是 US 的；
我的一些分析和猜测：
- fonts.googleapis.com 这些域名本身确实在北京有节点（大概率是事实）
- 1.1.1.1 并不支持 ECS ，所以并不会就近解析；
- 8.8.8.8 支持 ECS ，这台 SG 机器和某些 CN 碰巧在一个自治域内。国内用户（通过国内 DNS ）查询后，cdn 返回了国内的 ip ，同时这个请求被当前自治域的公共 dns 缓存。所以当国外用户查询（即使通过 8.8.8.8 ）的时候，公共 dns 就直接返回了缓存的国内 ip ，从而导致这个问题。
目前感觉除了替换 DNS 8.8.8.8 没有别的方案，话说有没有适合 SG 的本地的 DNS 服务器啊。 （ smartdns 里面配置用，SG 节点供应商未提供自己的 DNS 服务器）
22 条回复 • 2024-12-25 17:28:03 +08:00
 |
1
by 4 天前 via Android
你的新加坡 IP 可能是被 Google 送中了
试试 129.250.35.250 129.250.35.251 |
 |
2
infinityv OP @by 差不多就是第三点 被放在一个 AS 下了么。
这俩我试了下 和 1.1.1.1 差不多 都直接解析到 US 了。 因为 smartdns 会缓存最快的解析记录，所以感觉除非把 8.8.8.8 移掉 不然感觉一直有这个问题。好难顶 我的 SG 机器应该是套路云 SG 的节点 确实可能 AS 不干净 |
 |
3
gentrydeng 4 天前 via Android
既然你都在用 SmartDNS 了，也知道 ECS 。那为什么不直接指定一个地理位置能被正确识别 ECS ？
https://pymumu.github.io/smartdns/config/edns-client-subnet/ 发帖之前建议先自行查看程序文档来解决问题，而不是靠凭空想象。 而 1.1.1.1 不支持 ECS 不代表它就不是“就近解析”，只是依赖任播。 如果你的服务器访问 1.1.1.1 是被分配到 Cloudflare 新加坡节点。那么自然是通过 Cloudflare 新加坡节点进行 DNS 请求，这也是就近解析。 相反，支持 ECS 也不代表就是“就近解析”，因为 ECS 是可以被设置（伪装）的。 |
 |
4
yyzh 4 天前 via Android
g 家 dns 会送中很正常
4 条 1 如果解析到的是真位于美国的 ip 那就很不正常 |
 |
5
dream0689 4 天前 via iPhone  1
@yyzh 我遇到过 op 说的这种 4 个 1 解析到其他地区的情况。一般是商家没有把 cf 任播类地址路由调到当地的 ix 或者运营商出口跟 cf 直接 peer ，我当时是 sg 的机器走 singtel 到了 hkix ，延时 200ms+，这种情况使用 4 个 1 很多时候解析不仅慢还会返回 hk 解析结果，后来发工单找技术支持调路由到他们的 EQX SG 路由解决问题了。不过如果 op 所说 us 解析结果是在 SG 的广播地址，那是没有问题的。
|
|
6
dream0689 4 天前 via iPhone
楼主可以参考一下这个网站 https://publicdnsserver.com/singapore/
根据你的机器出口选择适合你的 subnet 。网站上的 dns 地址也可以试试。我平时用来测试内地到海外运营商的路由。 |
 |
7
yyysuo 4 天前
ecs 给 vps ip 就行了。
|
|
8
infinityv OP @dream0689 @gentrydeng 分开说哈。8.8.8.8 这个解析到国内 意思是即使我的公网地址即使物理位置在 SG ，但是 google 认为这个地址的 subnet 就是 CN 的么。
另外 1.1.1.1 Anycast 我明白，我说的意思有一些偏差，因为我对 ECS 是有一些误解。 现在看来 这个 SG 的机器被拿到的 1.1.1.1 广播地址看来也不对，这种应该是只能找厂家调路由出口吗 |
 |
9
mytsing520 4 天前
|
|
10
infinityv OP 综合看目前应该是没被送 中
|
|
11
dream0689 4 天前 via iPhone
@yyysuo 谷歌把 SG 的机器 ip 识别为 CN ip ，这个只能向谷歌提交反馈，谷歌说是一个月会调整，但也未必，基本无解，也就是这位朋友 @yyzh 说的被送中了。所有谷歌系都会被指向 CN 区域。这种情况尽量不要使用 4 个 8 进行解析。我的 SG 机器 ip 被识别成了 HK ip ，所以 gemini 之类的都用不了。油管的广告也是 HK 的。
你要先 trace 一下到 4 个 1 看走哪出的，如果不是从 sg 出的，再联系技术看不能调。但就算调了，也只是意味着 4 个 1 能就近解析了，谷歌系的解析 ip 结果也会是最近的，但服务区域仍将是 CN 区域的。 @mytsing520 基本上遇到的都是类似的情况。 问题的根源其实是机器 ip 不是原生 ip ，ip 注册地、注册公司、实际使用地(或是 gps 定位)三者不一致。 |
|
12
infinityv OP @dream0689 我现在其实油管啥的都能正常被识别为 SG 区。只是四个八的解析不对劲。 是不是可以说我的谷歌系服务没被送中，但是谷歌 dns 四个八 给我松中了
|
|
13
dream0689 4 天前 via iPhone
@infinityv 服务区域还在 SG ，就表示目前还没被送中。那应该改下机器的 dns 地址或者 smartdns 改一下 subnet 值就行了。如果要用 4 个 1 就在机器上 trace 一下，如果绕了就尝试寻求技术调一下路由。
|
|
14
infinityv OP @dream0689
[NextTrace API] preferred API IP - 172.67.155.192 - 149.19ms - Misaka.HKG IP Geo Data Provider: LeoMoeAPI traceroute to 1.1.1.1, 30 hops max, 52 bytes payload 1 * 2 * 3 10.54.243.133 * RFC1918 3.11 ms / 6.34 ms / 3.14 ms 4 * 5 116.251.66.230 AS45102 [Taobao] 中国 浙江 杭州 alibabagroup.com 3.90 ms / 3.05 ms / 2.96 ms 6 162.158.160.192 AS13335 [CLOUDFLARENET] 新加坡 cloudflare.com 3.05 ms / 2.86 ms / 3.05 ms 7 162.158.160.171 AS13335 [CLOUDFLARENET] 新加坡 cloudflare.com 7.98 ms / 45.92 ms / 47.26 ms 8 1.1.1.1 AS13335 CLOUDFLARE.COM cloudflare.com one.one.one.one 2.51 ms / 2.54 ms / 2.53 ms MapTrace URL: https://assets.nxtrace.org/tracemap/3ebd426d-3e79-5004-9ee5-eb400e67409d.html [NextTrace API] preferred API IP - 104.21.40.176 - 564.56ms - Misaka.LAX IP Geo Data Provider: LeoMoeAPI traceroute to 8.8.8.8, 30 hops max, 52 bytes payload 1 * 2 11.73.1.57 * DOD 53.09 ms / * ms / * ms 3 10.54.243.189 * RFC1918 2.72 ms / 2.65 ms / 2.85 ms 4 10.102.31.193 * RFC1918 2.54 ms / 2.48 ms / 2.47 ms 5 47.246.115.222 * 美国 加利福尼亚 San Mateo * ms / 52.95 ms / 58.91 ms 6 116.251.72.54 AS45102 [Taobao] 新加坡 alibabagroup.com 2.40 ms / 2.46 ms / 2.55 ms 7 142.251.254.17 AS15169 [GOOGLE] 新加坡 about.google 3.60 ms / 6.21 ms / 3.59 ms 8 72.14.232.107 AS15169 新加坡 about.google 3.19 ms / 3.18 ms / 3.21 ms 9 8.8.8.8 AS15169 GOOGLE.COM about.google dns.google 2.69 ms / 2.72 ms / 2.71 ms MapTrace URL: https://assets.nxtrace.org/tracemap/c4589c98-8c04-573a-a98b-7ec08292e333.html 感觉虽然都绕路了一下 但是最终跳都在 SG 很奇怪为啥 DNS 解析就是完全不对劲 |
|
15
mytsing520 3 天前
路由上的绕路与否，与他们数据库里认定你的 IP 送中，没有必然关联
|
|
16
dream0689 3 天前 via iPhone 1
@infinityv 从延迟看，两个地址都没绕，4 个 8 应该只是对机器 ip 识别的问题，会有给其他区域解析结果的可能。4 个 1 是递归解析，应该没问题，你看到的 us ip 解析结果，不等于服务器在 us ，得看延迟。sg 到 us 延迟 180ms 左右，或许你看到的解析 us ip 结果 ping 只有几 ms ，那就只不过是 us ip 在 sg 使用而已。
|
|
17
infinityv OP @dream0689 确实，理解了你的意思。目前看 1.1.1.1 的解析没有任何问题，虽然拿到的解析 ip 归属美国（好像不少谷歌 ip 都注册在他的 LA 总部） 但是其实应该是在新加坡用 时延都非常低。 四个 8 我制定了一个 DigitalOceal 家的 SG DNS Subnet 之后看着也没问题了。
|
 |
18
Pig930 3 天前
借楼问一下最近发现的一个奇怪现象，访问同样的 Google 搜索，Chrome 就会认为我的 IP 在香港，Safari 会认为我的 IP 在美国。Clash 分流是把 Google 分流到美国的 IEPL 节点了，Tun 模式也是开着的，看 log 在用 Chrome 的时候也没有被分流到香港节点的请求，非常百思不得其解
|
 |
19
Tianao 3 天前 via iPhone
我们客户有两条新加坡线路，一条去另一条绕比利时……
|
 |
20
JensenQian 2 天前
@infinityv 阿里云的 ip 用 8888 出问题很正常
|
|
21
infinityv OP @JensenQian 有啥说法吗。8888 对阿里云 ip 的 subnet 是不是都划到国内了啊
|
|
22
JensenQian 2 天前
|
Select Language