IP 错误报告汇总帖

[sjlleo]

格式参考下图：

219.158.24.82    中国 云南 昆明
202.97.77.13     中国 上海
221.183.89.1/24  中国 北京
218.30.54.102    美国 纽约州 纽约

如果您遇到 IP 错误，欢迎在下方反馈，您通常会在24小时内收到反馈结果。

为提高IP修正效率
对于可ping的IP，强烈建议附上ping.pe, ping.sx 或 itdog.cn 等监测网站的测试截图，
这将加快处理速度。

感谢您对 NextTrace 项目的支持。

---

优化体验，将此issue转移至discussion

[saga0324]

103.145.154.0/24 马来西亚 雪兰莪州 梳邦再也市 泰莱大学 MY Selangor Subang Jaya taylors.edu.my [TUSB-AS-AP,MY] AS139815 103.145.154.0/23 马来西亚 雪兰莪州 梳邦再也市 泰莱大学 MY Selangor Subang Jaya taylors.edu.my [TUSB-AS-AP,MY] AS139815 103.145.155.0/24 马来西亚 雪兰莪州 梳邦再也市 泰莱大学 MY Selangor Subang Jaya taylors.edu.my [TUSB-AP-AP,MY] AS139815

[sjlleo]

103.145.154.0/24 马来西亚 雪兰莪州 梳邦再也市 泰莱大学 MY Selangor Subang Jaya taylors.edu.my [TUSB-AS-AP,MY] AS139815 103.145.154.0/23 马来西亚 雪兰莪州 梳邦再也市 泰莱大学 MY Selangor Subang Jaya taylors.edu.my [TUSB-AS-AP,MY] AS139815 103.145.155.0/24 马来西亚 雪兰莪州 梳邦再也市 泰莱大学 MY Selangor Subang Jaya taylors.edu.my [TUSB-AP-AP,MY] AS139815

Fixed, thanks!

[stydxm]

202.97.107.93 不清楚是哪里，猜测是杭州，但一定不是香港

[stydxm]

202.97.96.205 猜测是南京 202.97.102.185 不知道是哪里，肯定不是hk 219.158.41.0/24 广西 219.158.119.69 广西 218.158.98.129 长沙或者湘潭 219.158.104.149 长沙或株洲 202.97.59.13 202.73.58 219.158.119.141 这几个已经完全不知道是哪的了 202.97.108.0/24 枣庄（也有可能不是，但一定是山东的） 202.97.73.58 长沙 221.183.128.21 湖南 这张图里不知道哪错了，北京上海广州都凑齐了，不知道哪个是对的，跟踪目标是218.252.31.137

[sjlleo]

@stydxm 谢啦，这跳应该是浙江金华，我去扫一下看看还有没有同一个段内是不是还有错的。

[samleong123]

223.28.43.90 & 202.185.6.226 属于 TIME 槟城 (Penang) speedpg.time.com.my 是 TIME 在槟城的服务器

[samleong123]

223.28.3.89 & 203.121.95.130 属于 TIME 柔佛新山 (Johor Bahru) ipv4-c001-jhb001-timedotcom-isp.1.oca.nflxvideo.net [203.121.95.130] 是 TIME在柔佛新山 (Johor Bahru) 的OCA

223.28.43.90 & 211.25.221.118 是 TIME 槟城 (Penang) ipv4-c002-pen001-timedotcom-isp.1.oca.nflxvideo.net [211.25.221.118] 是 TIME在槟城 (Penang) 的OCA

[samleong123]

58.27.108.236 (speedtest-sarawak.tm.com.my) 属于 马来西亚沙捞越 (Sarawak) TMNet (AS4788) 的测速服务器

[samleong123]

218.208.44.10 (speedtest-sabah.tm.com.my) 属于 马来西亚 沙巴 Penampang (Penampang , Sabah) TMNet (AS4788) 的测速服务器

[samleong123]

58.27.108.234 (speedtest-southern.tm.com.my) 属于 马来西亚马六甲 (Melaka) TMNet (AS4788) 的测速服务器

58.27.108.233 (speedtest-eastern.tm.com.my) 属于 马来西亚彭亨州Temerloh (Temerloh , Pahang)

[sjlleo]

58.27.108.234 (speedtest-southern.tm.com.my) 属于 马来西亚马六甲 (Melaka) TMNet (AS4788) 的测速服务器

58.27.108.233 (speedtest-eastern.tm.com.my) 属于 马来西亚彭亨州Temerloh (Temerloh , Pahang)

All Fixed!!! 非常感谢！

[stydxm]

202.97.97.10 浙江的，具体哪里不清楚，出现在从浙江到河南的中间一跳 202.97.100.157 江浙沪地区，出现在浙江到江苏南京中间一跳

[Eveaz]

202.97.103.146 AS4134 [CHINANET-BB] 中国 湖南省 武汉市 chinatelecom.cn 这是谁干的。。🤣 是武汉没错，但绝对不是湖南省啊。。

[sjlleo]

202.97.103.146 AS4134 [CHINANET-BB] 中国 湖南省 武汉市 chinatelecom.cn 这是谁干的。。🤣 是武汉没错，但绝对不是湖南省啊。。

大概率是跑脚本的时候跑出 BUG 来了。。。现在应该好了2333

[sjlleo]

202.97.97.10 浙江的，具体哪里不清楚，出现在从浙江到河南的中间一跳 202.97.100.157 江浙沪地区，出现在浙江到江苏南京中间一跳

202.97.97.10 河南郑州 202.97.100.157 江苏南京

Done!!!! Thank you~

[saga0324]

103.245.243.138/103.245.242.6 AS17660 [BTTELECOM-BT] BT Sarpang District Gelephu bt.bt 应该是不丹-印度跨境陆缆系统的不丹边境站 184.104.197.102 AS6939 [HURRICANE-11] MY Kuala Lumpur Kuala Lumpur he.net

[sjlleo]

103.245.243.138/103.245.242.6 AS17660 [BTTELECOM-BT] BT Sarpang District Gelephu bt.bt 应该是不丹-印度跨境陆缆系统的不丹边境站 184.104.197.102 AS6939 [HURRICANE-11] MY Kuala Lumpur Kuala Lumpur he.net

Done!

[stydxm]

219.158.119.69 广西联通 202.97.75.2不知道哪里 219.158.11.61黑龙江

[sjlleo]

202.97.75.2

202.97.75.2 河北石家庄

219.158.119.69 219.158.11.61 Done

Thank you very much!

[fkx4-p]

202.97.104.41 應爲北京/天津

[isyekong]

2606:4700::/44 Cloudflare CDN
2606:4700:3030::/44 Cloudflare CDN

不确定整段2606:4700::/36是否都为Anycast，还请验证

221.183.51.0/29 中国 江西 南昌
221.183.51.8/29 中国 河南 郑州
221.183.51.16/29 中国 贵州 贵阳
221.183.51.24/29 中国 云南 昆明
221.183.51.32/29 中国 云南 昆明
221.183.51.40/29 中国 甘肃 兰州
221.183.51.48/29 中国 江苏 南京
221.183.51.64/28 中国 上海
221.183.51.112/30 中国 河南 郑州
221.183.51.128/30 中国 河南 郑州
221.183.51.152 中国 河南 郑州
221.183.51.192/27 中国 上海
221.183.51.224/28 中国 上海
221.183.51.240/29中国 上海
221.183.51.248/29 中国 河南 郑州

221.176.106.181 中国 河南 郑州
221.183.57.61 中国 河南 郑州

其他问题：

比较好奇为什么有的地址返回的是英文地址，有的是中文呢？

以及运营商显示有点不统一，感觉都用域名或者org name来显示会比较统一

推荐根据rdns记录来补全地址库信息，很多境外运营商都有标注地理位置rdns，比如cogentco的rdns be3670.ccr22.sfo01.atlas.cogentco.com 如果数据量过大，也可以本地返回结果时，根据rdns动态显示结果

[sjlleo]

Hi Yekong,

非常感谢您提供的信息，对于您的疑问其实也是我一直想完善的事情，但是受限于曾经的设计问题，所以变动起来可能需要大量的时间和经历，这里我就一一回复啦，内容有点长，感谢您能抽出时间来阅读。

比较好奇为什么有的地址返回的是英文地址，有的是中文呢？

这个就得从 NextTrace 设计之初开始说起了，NextTrace 刚刚开始的时候理念非常单纯，只是想做一个直接调用其他库的普通带地理位置的路由跟踪微型 Project，既没有考虑过中英双语言，也没有叫想着校准里面的骨干网，所以数据库最初只是为了缓存用户的请求减少重复请求（从而减少 API 调用次数）而设计的。

后面我发现 NextTrace 使用的单一库（埃文科技）在国外骨干网上相较于 ipinsight，所提供的地理位置精确度其实是很一般的，所以更改为国外 ipinsight、国内埃文科技的2个 API 互补的情况，但是自从引入 ipinsight 以后，数据库里面的数据格式就开始混乱起来，因为 ipinsight 不提供中文，埃文科技不提供英文，所以自此出现了国外 ip 大部分是英文显示，国内 ip 全中文显示。

但到了开始启用 ipinsight 的时候，埃文科技其实也在先前提供了一部分国外的IP地理位置数据而且意见被缓存到库里面去了，这些也是中文显示的，所以在洛杉矶、圣何塞、西雅图这种非常容易命中缓存的地方，参合了大部分的中文数据。

当然后面手动批量校准数据的时候，也是以中文为主，校准后的数据也会从英文变成中文，导致在国外也会出现一跳英文一跳中文的情况，这个我自己其实也看了很难受，但是目前没有什么好的解决办法，何况后面 ipinsight 停止提供服务，现在国外使用的是 ipinfo 的 API，这2家的英文地理位置格式都不相同，目前只能先把国外的地理位置（英文）格式统一。

其实在昨天，我已经把新加坡、中国台湾的地理位置格式统一了，以前在测试的时候容易撞见

# 新加坡
新加坡,新加坡 // 手动校准，利用 OpenStreetMap API 自动填入的地理位置数据
新加坡, 新加坡, 新加坡 // 埃文科技
Singapore, Singapore // IPInsight
SG, Singapore, Singapore // IPinfo

4种不完全不同的格式却显示同一个地理位置，目前都统一成了 新加坡，他们来自于4个不同的来源，目前是在后端向 API 获取数据的时候检测到自动改成统一的格式，还有中国香港、中国台湾、中国澳门现在也都已经统一格式。

目前我在向 ipinfo 询问以他们自己规范起草的含有全世界各地区的地理位置的表格，当能维护好这张表的双语版本，混乱的中英文应该就不会再是一个问题，但是目前感觉想要拿到会比较困难，这事情不一定能成，我尽力而为。

以及运营商显示有点不统一，感觉都用域名或者org name来显示会比较统一

NextTrace 最初确实统一使用 org name 作为统一运营商显示，但是后面经很多朋友强烈要求，改成了域名显示。

域名信息是完全通过另外一个 API 获取的（叫 IPWhois），是完全免费的 API，它能返回 ASN 的域名信息，但是如果遇到没有 ASN 的 IP 地址，那就无法获取域名信息了，只能显示 org name 代替。

目前能够根据 IP 提供域名信息的（我能承担得起的）API 我没有找到，如果您知道的话可以告诉我哦。

推荐根据rdns记录来补全地址库信息，很多境外运营商都有标注地理位置rdns，比如cogentco的rdns be3670.ccr22.sfo01.atlas.cogentco.com 如果数据量过大，也可以本地返回结果时，根据rdns动态显示结果

基于 rDNS 的校准，目前已经在尝试了，微软的骨干网 IP 其实就是通过 rDNS 批量校准的，但是效果算不上好，而且每家 rDNS 的地理位置也有自己的规范，这个规则可能需要单独为每家 ISP “量身定制”。

比较正统的 ISP 会遵循国际机场 IATA 三位代码来标记地理位置，HE / Cogentco / Zayo / GTT / PCCW 皆在此列，但是像 NTT / Telstra / Level3 这种存在大量使用自家独特的地理位置格式来标记地理位置。

对于规范使用 IATA 的 ISP 会比较好维护，目前 IANA 代码对应的机场以及城市是有 open data 的，虽然没有州信息，但是可以后面再利用 OpenStreetMap API 来填入。

比如 NTT ae-3.r01.lsanca07.us.bb.gin.ntt.net. ae-3.ocn.tokyjp05.jp.bb.gin.ntt.net.，这种前4位代表城市简拼，后2位代表州就需要完全量身定做，网上也没有相关的开源资料有做过整合。

再比如 Level3 ae1.3508.ear3.Denver1.level3.net. 直接把城市名完整的写在里面，这就需要单独维护一份关于全世界城市信息的的数据表（虽然说不准可以复用 ipinfo 的地理位置信息，但是 level3 应该会和 ipinsight 格式接近）。

以上只是举几个例子，想要做 rDNS 匹配并没有那么容易，这事情会去做，但是具体“疗效”如何还是要逐步去完善。

PS: 我自始至终并没有去完全维护一个自己的 IP 库的想法，首先我想我肯定没有那个人力物力去实现它，或许我能做的就是站在巨人的肩膀上，凭借我们自身的能力，去制作一个更好的 Traceroute 软件，正是这个过程我才能更加体会到 IPIP 精准度之高绝非易事。

作为一款路由跟踪的小工具，我很清楚 IP 骨干网的准度必然是其中的一环，但冰冻三尺非一日之寒，一旦引入 IP 地理位置信息的精准度要求，门槛就会变得很高，又要用爱发电，又要挤出大量的时间去完善它，使得 NextTrace 这款软件的开发处在一个非常尴尬的状况。

目前 NextTrace 并不成熟，去实现这些功能，本质上来说就是去做另外一个 IP 库，这和我之前的想法相悖，但是如果要提升体验，就应该去做一个哪怕类似于 IP 库，含有手动标记段的微型库，如果按这个去做，又得花费大量的时间。

所以我决定慢慢做，有空就做一点，也不求能有多准，能做一点是一点为好，兴趣终究是兴趣，再感兴趣也注定无法成为我生活中的主旋律，它在未来或许会变得更好，但是这需要长时间的积累，而非点石成金。

以上。

Best Regards, Leo Shen

[sjlleo]

202.97.104.41 應爲北京/天津

Hi FFEE_CO,

202.97.104.41 是在河北石家庄哦，应该没有错误~

[isyekong]

感谢您耐心解答~

其实在昨天，我已经把新加坡、中国台湾的地理位置格式统一了，以前在测试的时候容易撞见

我发现台湾的地址格式还是有些奇怪，出现了三种中文格式 中国 中国台湾 台北市 中国 台湾 台北 中国 台湾省 台北市

如果有合适的API我会再反馈的，非常感谢您的贡献

[sjlleo]

感谢您耐心解答~

其实在昨天，我已经把新加坡、中国台湾的地理位置格式统一了，以前在测试的时候容易撞见

我发现台湾的地址格式还是有些奇怪，出现了三种中文格式 中国 中国台湾 台北市 中国 台湾 台北 中国 台湾省 台北市

如果有合适的API我会再反馈的，非常感谢您的贡献

现在应该好了，再试试哦😂

[sjlleo]

推荐根据rdns记录来补全地址库信息，很多境外运营商都有标注地理位置rdns，比如cogentco的rdns be3670.ccr22.sfo01.atlas.cogentco.com 如果数据量过大，也可以本地返回结果时，根据rdns动态显示结果

我倒是有个想法，可以把一些常见的 rDNS 地理位置（IATA）先罗列出来，然后单独存放在一个 List 里面，这样至少热门地区就不会出错了。

北美

tpa - 坦帕 den - 丹佛 nyc - 纽约 buf - 水牛城 ash - 阿什本 phx - 凤凰城 lax - 洛杉矶 sjc - 圣何塞 sjo - 圣何塞 sfo - 旧金山 sea - 西雅图 pdx - 波特兰 mci - 北堪萨斯城 mia - 迈阿密 dal - 达拉斯 ewr - 纽瓦克 chi - 芝加哥 yvr - 温哥华 ywg - 温尼伯 tor - 多伦多 atl - 亚特兰大 fmt - 弗里蒙特 las - 拉斯维加斯

中国

hk - 香港 hkg - 香港 hkb - 香港 tao - 桃园 tpe - 台北

马来西亚

pen - 槟城 jhb - 柔佛新山 kul - 吉隆坡

新加坡

qpg - 新加坡 sgp - 新加坡 sg - 新加坡

澳大利亚

syn - 悉尼 mel - 墨尔本

日本

tyo - 东京 tky - 东京 hnd - 东京 nrt - 千叶 osa - 大阪

韩国

sel - 首尔 qun - 春川

英国

lon - 伦敦

德国

fra - 法兰克福 ham - 汉堡

法国

par - 巴黎 mrs - 马赛

奥地利

vie - 维也纳

塞尔维亚

beg - 贝尔格莱德

卢森堡

lux - 卢森堡

波兰

ktw - 卡托维兹

罗马尼亚

buh - 布加勒斯特

捷克

prg - 布拉格

斯洛伐克

bts - 布拉迪斯拉发

阿联酋

dxb - 迪拜

吉布提

jib - 吉布提市

南非

jnb - 约翰内斯堡

您看看有什么需要补充的吗？

[isyekong]

新加坡

qpg - 新加坡 sgp - 新加坡 sg - 新加坡

新加坡补充一下 sin

新加坡的IATA 是 SIN，SGP应该是ISO 3166-1代码？其实我也觉得挺混乱的，cogent用的也是sin te0-0-0-23.agr01.sin01.atlas.cogentco.com 感觉把城市名也都加上好了..像level3、Tata就是用的城市名 ix-ae-10-0.thar1.svq-singapore.as6453.net ae1.3504.edge2.Singapore3.level3.net

德国 dus - 杜塞尔多夫 nue - 纽伦堡 muc - 慕尼黑

荷兰 ams - 阿姆斯特丹

把位置信息文件放到github让大家一起维护会不会更好一些~

[isyekong]

206.223.116.0/23 美国 加利福尼亚州 圣何塞 Equinix

这里的ASN是哪里读取的呀？似乎是没有宣告的prefix

[sjlleo]

206.223.116.0/23 美国 加利福尼亚州 圣何塞 Equinix

这里的ASN是哪里读取的呀？似乎是没有宣告的prefix

我查了一下，是埃文科技的 API 提供的信息，里面包含了 ASN 为 4637。

[sjlleo]

把位置信息文件放到github让大家一起维护会不会更好一些~

好哦，我在整理这个，明天单独开个项目，专门存放这个数据吧。

[sjlleo]

把位置信息文件放到github让大家一起维护会不会更好一些~

Now it's available: https://github.com/sjlleo/isp-geo-code-data

[stydxm]

202.97.96.125 京津冀 217.158.17.81 可能是上海或者青岛 213.155.130.177 195.12.255.210 美国（这个根据ping判断的，有些库是瑞典，但欧洲的服务器普遍100+美国服务器50-） 64.71.162.42 美国弗里蒙特（rdns里有fmt，不知为何没有匹配上，从ping看也是在弗里蒙特） 103.175.99.34 美国弗里蒙特（根据ping判断，在ip库里是阿根廷，好像是故意伪装成阿根廷地区的机场节点） 144.232.15.239 美国，但是禁ping

[sjlleo]

Hi stydxm,

IP 校准名单真实地理位置如下，非常感谢：

202.97.96.125 中国 河北省 石家庄市
219.158.17.81 中国 吉林省 长春市
213.155.130.177 美国 密苏里州 堪萨斯城
62.115.125.185 美国 加利福尼亚州 帕洛阿托
195.12.255.210 美国 加利福尼亚州 帕洛阿托
64.71.162.42 美国 加利福尼亚州 弗里蒙特
103.175.99.34 美国 加利福尼亚州 弗里蒙特
144.232.15.239 美国 加利福尼亚州 斯托克顿

rdns里有fmt，不知为何没有匹配上，从ping看也是在弗里蒙特

后端只会在 IP 入库时获取一次 rDNS 信息，随后进入缓存，如果首次获取失败，或者入库时还没有IP的 rDNS 还未注册，就会出现这种情况~

这些 IP 将在今天更新完成，期待您的下一次提交

Leo

[stydxm]

62.115.179.102 德国，大概率法兰克福 202.97.25.230 上海或者浙江某地，这次路由跟踪的目的地位于浙北，但是数据错误的这一跳之后全是* 93.191.9.114 62.140.239.28 80.77.167.77 应该都是俄罗斯的而不是美国 最后两跳的吉尔吉斯斯坦 比什凯克被标成了比什凯克 比什凯克 这里的安道尔按别的数据的格式，可能标成安道尔 安道尔城更合理一些？ 176.96.243.1 乌兹别克斯坦，大概率塔什干 157.119.185.210 查了好久，Chittagong Division Lakshmipur翻译应该是吉大港区罗基布尔，Dhaka Division Naya Paltan是达卡区帕尔坦的一个地方，但没找到通用的中文翻译 202.97.36.18 不知道在哪，估计非洲，国内ping200+，欧洲ping300+，美国ping400+

[sjlleo]

62.115.179.102 德国 黑森州 法兰克福
93.191.9.114 立陶宛 维尔纽斯县 维尔纽斯
62.140.239.28 俄罗斯 莫斯科州 莫斯科
80.77.167.77 俄罗斯 莫斯科州 莫斯科
176.96.243.1 乌兹别克斯坦 塔什干州 塔什干
202.97.36.18 肯尼亚 内罗毕

202.97.25.230 这跳确实是在香港，香港 Azure ping 过去延时仅 1.2ms，之前被校准过一次，应该不会错。

安道尔的数据是我上月校准的，之所以只精确到安道尔国家级别是因为没办法更加精确了，缺少这个国家的监测节点。

对于地名的中文翻译一般是如果有中文那就显示中文，如果没有中文的话还是直接显示英文为好，否则哪怕翻译成了中文，在Google 地图上直接搜索也找不到这个地方。

比什凯克是个翻译错误，感谢纠正，现在已经正常了。

以上，非常感谢。

Leo

[sjlleo]

Hi @zdm9981,

您提到的 IP 现都已经校准完成，均在安徽省合肥市。

感谢您的反馈，目前 LeoMoeAPI 对于安徽省的联通169、9929以及CN2骨干网数据都有明显的缺失，期待您的更多提交。

Leo

[AlexHuang3]

59.43.245.9 洛杉矶 电信（CN2？
218.30.49.90 洛杉矶 电信

这两个应该都是洛杉矶电信的节点 为啥都识别出是ChinaNet-US还会给北京的地址呢

5.56.20.170
5.255.66.195 两个应该都是在 荷兰 弗莱福兰省 德龙滕
81.95.2.138 这个应该是阿姆斯特丹

202.97.86.85 中国 浙江 金华

202.97.36.161 广东 广州

[sjlleo]

Hi @AlexHuang3

为啥都识别出是ChinaNet-US还会给北京的地址呢

因为 NextTrace 里面有好多张表，每张表负责的内容不一样，这个 ChinaNet-US 是我手动把 218.30.49.0/24 整个段加进去了，但是我并没有把整个段都标记成“美国”，因为大部分时候第三方api能给出一个正确的地址。

218.30.49.90 这个 IP 测试的时候还是 ping 不通的，故没有入库。

第一次入库的具体地理位置默认从第三方 API 获得的，目前 LeoMoeAPI 后端至少有 3个数据源在同时工作，程序会努力找出正确的那个，但是因为这个 IP 无法 ping 通，我们也无从得知他真实的地理位置。

这种情况，我们一般称之为“就不告诉你”，因为只有路由正好测到的时候才会显示，这需要大量的监测节点，互相来回路由跟踪，而且是路由跟踪到特定的监测节点，才有机会正好试到这个 IP，概率太小了，NextTrace 作为一个开源项目，不可能购买如此多的检测点。

所以我们通常对于此类骨干网，采取的是用户先测，后校准的方案，也就是如果有用户路由跟踪遇到了这个 IP，第三方库会先给出一个地理位置，未必是精准的，我们会在后续去校准它，所以如果您发现一些没有rDNS，但是骨干网却很准，这并非第三方库准，而是之前有用户已经测到过这个 ip，并且我们已经校准了，所以才会看起来特别准。

对于一些没有 rDNS 的骨干网来说，校准是很困难的，特别是对于 CN2 来说，因为 59.43 整个段没有对外广播，所以只有电信才可以 ping 通这里面部分 ip，而且您刚刚提到的那个 59.43.245.9 连电信也无法 ping 不通，所以可以参照为什么 218.30.49.90 无法被校准。

您可以参考我们之前发布的骨干网准度报告，我们当前库的 CN2 骨干网准度连 50％ 都没有，这并非我们不努力，而是很多时候我们无法通过外面得知这个 ip 的真实位置，能做的只有等一天有用户测到了，入库后就正确了。

有些时候，一些骨干网 ip 是必须有了钞能力，才是可以校准的。

您的其他 ip 都已经顺利更新，感谢您的反馈。我们也期待您的更多 ip 上报。

谢谢！

[plasmafree]

为啥不先去测一下 那样地址就对了啊。。。

[isyekong]

为啥不先去测一下 那样地址就对了啊。。。

地址数量庞大， NextTrace 只是一个开源项目，没有如此多的时间和资金去购买监测点。 上面的回复已经很明白了，当有用户测到这个 IP 后，会在后端自动进行测试和更新。

以及电信 CN2 59.43 段是没有宣告的，外网无法测出这个 IP 的真实位置和路由，只有收集大量的测试数据，根据上下跳关系、延迟等数据，才可以判断真实的位置。

[AlexHuang3]

Hi @AlexHuang3

为啥都识别出是ChinaNet-US还会给北京的地址呢

因为 NextTrace 里面有好多张表，每张表负责的内容不一样，这个 ChinaNet-US 是我手动把 218.30.49.0/24 整个段加进去了，但是我并没有把整个段都标记成“美国”，因为大部分时候第三方api能给出一个正确的地址。

218.30.49.90 这个 IP 测试的时候还是 ping 不通的，故没有入库。

第一次入库的具体地理位置默认从第三方 API 获得的，目前 LeoMoeAPI 后端至少有 3个数据源在同时工作，程序会努力找出正确的那个，但是因为这个 IP 无法 ping 通，我们也无从得知他真实的地理位置。

这种情况，我们一般称之为“就不告诉你”，因为只有路由正好测到的时候才会显示，这需要大量的监测节点，互相来回路由跟踪，而且是路由跟踪到特定的监测节点，才有机会正好试到这个 IP，概率太小了，NextTrace 作为一个开源项目，不可能购买如此多的检测点。

所以我们通常对于此类骨干网，采取的是用户先测，后校准的方案，也就是如果有用户路由跟踪遇到了这个 IP，第三方库会先给出一个地理位置，未必是精准的，我们会在后续去校准它，所以如果您发现一些没有rDNS，但是骨干网却很准，这并非第三方库准，而是之前有用户已经测到过这个 ip，并且我们已经校准了，所以才会看起来特别准。

对于一些没有 rDNS 的骨干网来说，校准是很困难的，特别是对于 CN2 来说，因为 59.43 整个段没有对外广播，所以只有电信才可以 ping 通这里面部分 ip，而且您刚刚提到的那个 59.43.245.9 连电信也无法 ping 不通，所以可以参照为什么 218.30.49.90 无法被校准。

您可以参考我们之前发布的骨干网准度报告，我们当前库的 CN2 骨干网准度连 50％ 都没有，这并非我们不努力，而是很多时候我们无法通过外面得知这个 ip 的真实位置，能做的只有等一天有用户测到了，入库后就正确了。

有些时候，一些骨干网 ip 是必须有了钞能力，才是可以校准的。

您的其他 ip 都已经顺利更新，感谢您的反馈。我们也期待您的更多 ip 上报。

谢谢！

非常感谢解释，也感谢您的开源项目，对我很有帮助 另外再奉上两个IP 202.97.71.205 中国 四川省 成都市 我个人倾向于是在成都而不是丽江

69.194.186.202  这个IP Ping不通，不过应该是属于CTG香港的
192.252.180.123  应该也是在香港

[sjlleo]

非常感谢解释，也感谢您的开源项目，对我很有帮助 另外再奉上两个IP 202.97.71.205 中国 四川省 成都市 我个人倾向于是在成都而不是丽江

69.194.186.202  这个IP Ping不通，不过应该是属于CTG香港的
192.252.180.123  应该也是在香港

谢谢！您反馈的几个 IP 都已经修改过来了。

[LiXin-x]

12 和 13，根据

• https://db-ip.com/223.120.13.221
• https://db-ip.com/223.120.2.190
• 223.120.0.0/16 Netblock Whois Information - AS58453 CMI-INT-HK - China Mobile International Limited, HK | IPIP.NET

• 223.120.0.0/16 应该是 CMI-INT-HK，中国香港 麻烦验证修正。

[sjlleo]

12 和 13，根据

• https://db-ip.com/223.120.13.221
• https://db-ip.com/223.120.2.190
• 223.120.0.0/16 Netblock Whois Information - AS58453 CMI-INT-HK - China Mobile International Limited, HK | IPIP.NET

• 223.120.0.0/16 应该是 CMI-INT-HK，中国香港 麻烦验证修正。

hi，

223.120.0.0/16 是中国移动国际公司的骨干网段，位置遍布世界全球，而非只在中国香港。

我们对您提到的 IP 进行了验证，没有发现错误。

223.120.2.190 没有发现错误，确实在日本东京，我们使用东京 DMIT 和 东京 NeroCloud 进行了验证。

223.120.13.221 同样也没有发现错误，我们使用圣何塞 DMIT 和圣何塞 Misaka 进行了验证，确定了它确实在美国加利福尼亚州圣何塞。

谢谢

[LiXin-x]

@sjlleo 辛苦了，刚刚接触并不能自行验证。因为之前 BestTrace 测澳大利亚线路基本走香港，所以怀疑是出错了。谢谢验证

[Lutra-Fs]

3 4 应为 悉尼 7 应为 关岛 e50.theisland.gslnetworks.com 9 应为东京

[tsosunchia]

3 4 应为 悉尼 7 应为 关岛 e50.theisland.gslnetworks.com 9 应为东京

感谢您的反馈，已变更

[Lutra-Fs]

感谢您的反馈，已变更

看到了 3 4 7 的修改，9仍然显示为悉尼. Also, for GSL network, it seems like it does support rDNS for most nodes. Could we add extraction from rDNS for it as currently most of the nodes are resolved to Los Angeles. 7跳为Perth 8跳为Singapore

[tsosunchia]

已修正，

Also, for GSL network, it seems like it does support rDNS for most nodes. Could we add extraction from rDNS for it as currently most of the nodes are resolved to Los Angeles.

RDNS的解析我们是有做的，但是在满足一些特定条件下才会启用(我们更相信来自上游的信息，很多IP的RDNS并不是非常准确)

[sjlleo]

GSL 网络目前没有启用 rDNS 的解析功能，因为曾经开启过 rDNS 解析出现了大量标识错误，现在只会获取上游的信息。 我们会重新研究这个问题，尽早为 GSL 网络应用这个功能。