IP 错误报告汇总帖
sjlleo opened this issue · 186 comments
格式参考下图：
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
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
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!
202.97.107.93 不清楚是哪里，猜测是杭州，但一定不是香港
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
223.28.43.90 & 202.185.6.226 属于 TIME 槟城 (Penang)
speedpg.time.com.my 是 TIME 在槟城的服务器
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
58.27.108.236 (speedtest-sarawak.tm.com.my) 属于 马来西亚沙捞越 (Sarawak) TMNet (AS4788) 的测速服务器
218.208.44.10 (speedtest-sabah.tm.com.my) 属于 马来西亚 沙巴 Penampang (Penampang , Sabah) TMNet (AS4788) 的测速服务器
58.27.108.234 (speedtest-southern.tm.com.my) 属于 马来西亚马六甲 (Melaka) TMNet (AS4788) 的测速服务器
58.27.108.233 (speedtest-eastern.tm.com.my) 属于 马来西亚彭亨州Temerloh (Temerloh , Pahang)
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!!! 非常感谢！
202.97.97.10 浙江的，具体哪里不清楚，出现在从浙江到河南的中间一跳
202.97.100.157 江浙沪地区，出现在浙江到江苏南京中间一跳
202.97.103.146 AS4134 [CHINANET-BB] ** 湖南省 武汉市 chinatelecom.cn
这是谁干的。。🤣
是武汉没错，但绝对不是湖南省啊。。
202.97.103.146 AS4134 [CHINANET-BB] ** 湖南省 武汉市 chinatelecom.cn这是谁干的。。🤣 是武汉没错，但绝对不是湖南省啊。。
大概率是跑脚本的时候跑出 BUG 来了。。。现在应该好了2333
202.97.97.10 浙江的，具体哪里不清楚，出现在从浙江到河南的中间一跳 202.97.100.157 江浙沪地区，出现在浙江到江苏南京中间一跳
202.97.97.10 河南郑州
202.97.100.157 江苏南京
Done!!!! Thank you~
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
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!
219.158.119.69 广西联通
202.97.75.2不知道哪里 219.158.11.61黑龙江
202.97.75.2
202.97.75.2 河北石家庄
219.158.119.69 219.158.11.61 Done
Thank you very much!
202.97.104.41 應爲北京/天津
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动态显示结果
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
202.97.104.41 應爲北京/天津
Hi FFEE_CO,
202.97.104.41 是在河北石家庄哦，应该没有错误~
感谢您耐心解答~
其实在昨天，我已经把新加坡、****的地理位置格式统一了，以前在测试的时候容易撞见
我发现**的地址格式还是有些奇怪，出现了三种中文格式
** **** 台北市
** ** 台北
** **省 台北市
如果有合适的API我会再反馈的，非常感谢您的贡献
感谢您耐心解答~
其实在昨天，我已经把新加坡、****的地理位置格式统一了，以前在测试的时候容易撞见
** **** 台北市** ** 台北** **省 台北市如果有合适的API我会再反馈的，非常感谢您的贡献
现在应该好了，再试试哦😂
推荐根据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 - 约翰内斯堡
您看看有什么需要补充的吗？
新加坡
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让大家一起维护会不会更好一些~
206.223.116.0/23 美国 加利福尼亚州 圣何塞 Equinix
这里的ASN是哪里读取的呀？似乎是没有宣告的prefix
206.223.116.0/23 美国 加利福尼亚州 圣何塞 Equinix
这里的ASN是哪里读取的呀？似乎是没有宣告的prefix
我查了一下，是埃文科技的 API 提供的信息，里面包含了 ASN 为 4637。
把位置信息文件放到github让大家一起维护会不会更好一些~
好哦，我在整理这个，明天单独开个项目，专门存放这个数据吧。
把位置信息文件放到github让大家一起维护会不会更好一些~
Now it's available: https://github.com/sjlleo/isp-geo-code-data
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
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
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+
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
Hi @zdm9981,
您提到的 IP 现都已经校准完成，均在安徽省合肥市。
感谢您的反馈，目前 LeoMoeAPI 对于安徽省的联通169、9929以及CN2骨干网数据都有明显的缺失，期待您的更多提交。
Leo
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 广东 广州
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 上报。
谢谢！
为啥不先去测一下 那样地址就对了啊。。。
为啥不先去测一下 那样地址就对了啊。。。
地址数量庞大， NextTrace 只是一个开源项目，没有如此多的时间和资金去购买监测点。
上面的回复已经很明白了，当有用户测到这个 IP 后，会在后端自动进行测试和更新。
以及电信 CN2 59.43 段是没有宣告的，外网无法测出这个 IP 的真实位置和路由，只有收集大量的测试数据，根据上下跳关系、延迟等数据，才可以判断真实的位置。
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 应该也是在香港
非常感谢解释，也感谢您的开源项目，对我很有帮助
另外再奉上两个IP
202.97.71.205 ** 四川省 成都市
我个人倾向于是在成都而不是丽江
69.194.186.202 这个IP Ping不通，不过应该是属于CTG香港的 192.252.180.123 应该也是在香港
谢谢！您反馈的几个 IP 都已经修改过来了。
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，**香港
麻烦验证修正。
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 进行了验证，确定了它确实在美国加利福尼亚州圣何塞。
谢谢
3 4 应为 悉尼
7 应为 关岛 e50.theisland.gslnetworks.com
9 应为东京
感谢您的反馈，已变更
感谢您的反馈，已变更
看到了 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
已修正，
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并不是非常准确)
GSL 网络目前没有启用 rDNS 的解析功能，因为曾经开启过 rDNS 解析出现了大量标识错误，现在只会获取上游的信息。
我们会重新研究这个问题，尽早为 GSL 网络应用这个功能。
这里的3.3.3.1应该是局域网劫持的DNS服务器
想问一下这种情况好识别并修改吗？
还有就是114DNS会被识别到美国Cogent去，但是它应该是一个Anycast地址
中间的202.97.67.198和74.125.49.8根据延迟看应该是香港的，ipip.net查也是香港的
这里的3.3.3.1应该是局域网劫持的DNS服务器
抱歉，这种情况我们不会修改，因为我们不赞成把已经在全世界宣告的IP地址段重新划分为内网使用。
中间的202.97.67.198和74.125.49.8根据延迟看应该是香港的，ipip.net查也是香港的
202.97.67.198 和 74.125.49.8 已修正，可能需要等待几分钟以生效。
Thanks!
24 应为 新加坡市
25、26、27和28 均应为 香港
30 应为 洛杉矶市
以及文字版本的结果
24 129.250.4.73 * 局域网
ae-1.r22.sngpsi07.sg.bb.gin.ntt.net * ms / * ms / 369.04 ms
25 129.250.7.67 * 局域网
ae-10.r27.tkokhk01.hk.bb.gin.ntt.net 380.15 ms / 382.81 ms / 379.49 ms
26 129.250.5.28 * 局域网
ae-0.r26.tkokhk01.hk.bb.gin.ntt.net 373.34 ms / 373.62 ms / 372.90 ms
27 129.250.6.92 * 局域网
ae-1.r02.tkokhk01.hk.bb.gin.ntt.net 374.27 ms / 373.60 ms / 373.44 ms
28 203.131.241.110 * 局域网
ce-0-1-0-2.r02.tkokhk01.hk.ce.gin.ntt.net 236.66 ms / 236.06 ms / 236.21 ms
29 *
30 23.225.55.13 * 局域网
23.225.55-13.ceranetworks.com 236.05 ms / 236.36 ms / 235.90 ms / * ms / * ms / * ms
MapTrace URL: https://api.leo.moe/tracemap/c3b225f7-84fe-545b-86ad-f9c8b69d2d60.html
8 应为 CERNET，陕西西安
9 应为 CERNET，广东深圳
12、13和14 均应为 CERNET，北京
相应的文字版本：
8 202.200.29.5 * 局域网
7.50 ms / 5.53 ms / 4.98 ms
9 101.4.117.178 * 局域网
4.33 ms / 12.26 ms / 4.55 ms
10 *
11 *
12 101.4.115.114 * 局域网
* ms / 20.80 ms / 20.94 ms
13 101.4.114.194 * 局域网
21.27 ms / 21.63 ms / 21.81 ms
14 101.4.114.182 * 局域网
53.75 ms / 53.63 ms / 56.65 ms
辛苦了
感谢您的反馈，
我们的api在这部分大概是没问题的，您看到这里ip位置显示为局域网，原因应该是您与api服务的连接出现了问题，多试几次应该就没问题了。
感谢您的反馈， 我们的api在这部分大概是没问题的，您看到这里ip位置显示为
局域网，原因应该是您与api服务的连接出现了问题，多试几次应该就没问题了。
@tsosunchia
谢谢您的回复。
确实是我自己的问题。
不过逐一分析发现，似乎 101.4.115.114 的位置应为 CERNET 北京？从前后跳的ping来看似乎不太可能属于成都。
不过逐一分析发现，似乎 101.4.115.114 的位置应为 CERNET 北京？从前后跳的ping来看似乎不太可能属于成都。
Hi @morninghut,
确实如您所说的，我已经更新了这个 IP 的地理位置，请您再试试。
Best Regards,
Leo Shen
不过逐一分析发现，似乎 101.4.115.114 的位置应为 CERNET 北京？从前后跳的ping来看似乎不太可能属于成都。
Hi @morninghut,
确实如您所说的，我已经更新了这个 IP 的地理位置，请您再试试。
Best Regards, Leo Shen
已经看到了修改。辛苦了
219.158.10.30这个IP被错误标注成了北京
下图是这个IP在ping.pe的测试，可见其应当在深圳广州附近
@7ith1um 根据您的要求，您的 comment 已经被删除~ 感谢您对 NextTrace 做出的贡献！
tsosunchia 的一些评论中引用了我上传的图片，希望也能一并删除。
202.97.74.225 202.97.74.226 北京电信
以下是 nexttrace 输出：
124.75.75.241 AS4812 [CHINANET-SH] ** 上海市 chinatelecom.cn 电信
0.52 ms / * ms / * ms
61.152.54.177 AS4812 [CHINANET-SH] ** 上海市 chinatelecom.cn 电信
0.51 ms / * ms / * ms
*
*
202.97.74.226 AS4134 [CHINANET-BB] ** 广西壮族自治区 chinatelecom.com.cn 电信
16.43 ms / 16.43 ms / 16.15 ms
101.4.117.109 AS4538 [BJR-CERNET] ** 北京市 cernet.edu.cn 教育网
55.10 ms / 53.06 ms / 46.77 ms
101.4.116.65 AS4538 [BJR-CERNET] ** 北京市 cernet.edu.cn 教育网
48.71 ms / 48.62 ms / 59.02 ms
47.246.114.2 香港 alibabagroup.com
47.246.116.126 香港 alibabagroup.com
99.84.200.0/21 美国 加利福尼亚州 洛杉矶 CLOUDFRONT amazon.com
54.230.20.0/22 美国 加利福尼亚州 洛杉矶 CLOUDFRONT amazon.com
219.158.110.53 ** 广东省 chinaunicom.cn 联通
59.43.38.170 ** 上海市 chinatelecom.cn 电信
69.194.166.190 新加坡 chinatelecomglobal.com 电信
59.43.247.234 ** 上海市 chinatelecom.cn 电信
您好，请问一直提示 websocket: bad handshake ASAPI Server Error 是什么情况，！
您好，请问一直提示 websocket： 糟糕的握手 ASAPI 服务器错误 是什么情况，！
您好，请问一直提示 websocket： 糟糕的握手 ASAPI 服务器错误 是什么情况，！
大陆部分地区对api.leo.moe有ws阻断，这不是我们能解决的，建议您换个网络环境。
另外此issue下不要发其他问题。
第 10 和 11 跳应该都是美国，具体地址不太确定hmmm
IP如下：
- 2001:4860::c:4001:35d
- 2001:4860::c:4002:2166
- 2001:4860::c:4000:e102
* 2001:4860::c:4001:35d * 2001:4860::c:4002:2166 * 2001:4860::c:4000:e102
好耶，谢谢苏苏 qwq
2001:4860::c:4001:35d 应该在日本的千叶县哦，Google 海缆的出口地~
下面是日本东京某台辣鸡服务器 ping 这个 IP 的延迟
2001:4860::c:4002:2166 应该就在日本的东京~
2001:4860::c:4000:e102 应该也在日本的千叶县哦
一会儿在千叶一会儿在东京可能是 TCP 下 Google 骨干网的负载均衡吧 2333
我怀疑 Google 的骨干网可能是有 MPLS，所以在 traceroute 的时候包从西海岸波特率绕了一圈，看起来延迟就像是西海岸的节点
[NextTrace API] prefered API IP - 104.26.9.231 - 1.05ms
IP Geo Data Provider: LeoMoeAPI
traceroute to 112.53.68.97, 30 hops max, 32 byte packets
1 38.47.116.254 AS979 美国 加利福尼亚州 洛杉矶 as979.net
18.71 ms / 102.45 ms / 13.32 ms
2 10.9.8.7 * [RFC1918] 局域网
0.58 ms / 1.23 ms / 0.70 ms
3 *
4 *
5 59.43.189.37 * [CN2-BackBone] ** 上海市 chinatelecom.cn 电信
127.14 ms / 126.87 ms / 127.21 ms
6 59.43.187.85 * [CN2-BackBone] ** 上海市 chinatelecom.cn 电信
128.10 ms / 228.71 ms / * ms
7 59.43.138.69 * [CN2-BackBone] ** 上海市 chinatelecom.cn 电信
128.78 ms / 132.48 ms / 140.93 ms
8 59.43.80.145 * [CN2-BackBone] ** 上海市 chinatelecom.cn 电信
132.86 ms / * ms / 233.98 ms
9 202.97.95.242 AS4134 [CHINANET-BB] ** 山东省 chinatelecom.com.cn 电信
153.10 ms / 153.09 ms / 153.06 ms
10 *
11 *
12 221.183.129.153 AS9808 [CMNET] ** 湖北省 chinamobile.com 移动
272.45 ms / 272.78 ms / * ms
13 *
14 211.137.196.54 AS24444 [CMNET] ** 山东省 临沂市 chinamobile.com 移动
178.63 ms / 179.01 ms / 178.65 ms
15 112.53.68.97 AS24444 [APNIC-AP] ** 山东省 临沂市 chinamobile.com 移动
178.27 ms / 178.25 ms / 178.21 ms
MapTrace URL: https://api.leo.moe/tracemap/8d3c1c75-6bf9-50f9-bea2-819c6a68be57.html
[NextTrace API] prefered API IP - 104.26.9.231 - 1.34ms
IP Geo Data Provider: LeoMoeAPI
traceroute to 112.53.68.97, 30 hops max, 32 byte packets
1 *
2 10.5.4.3 * [RFC1918] 局域网
1.37 ms / 2.65 ms
10.6.5.4 * [RFC1918] 局域网
2.96 ms
3 162.219.85.77 AS10099 [CUG-BACKBONE] 美国 加利福尼亚州 洛杉矶 chinaunicomglobal.com 联通
1.08 ms / 1.57 ms / 1.87 ms
4 203.160.75.218 AS10099 [CUG-BACKBONE] ** 上海市 chinaunicomglobal.com 联通
134.75 ms / 135.14 ms
162.219.85.1 AS10099 [CUG-BACKBONE] ** 上海市 chinaunicomglobal.com 联通
129.65 ms
5 218.105.2.89 AS9929 [CNC-BACKBONE] ** 上海市 chinaunicom.cn 联通 CUII
139.88 ms
218.105.2.93 AS9929 [CNC-BACKBONE] ** 上海市 chinaunicom.cn 联通 CUII
130.92 ms / 131.44 ms
6 218.105.2.150 AS9929 [CNC-BACKBONE] ** 上海市 chinaunicom.cn 联通 CUII
133.53 ms / 139.48 ms / 139.80 ms
7 219.158.32.1 AS4837 [CU169-BACKBONE] ** 上海市 chinaunicom.cn 联通
134.18 ms / 135.23 ms / 141.71 ms
8 *
9 219.158.118.138 AS4837 [CU169-BACKBONE] ** 北京市 chinaunicom.cn 联通
144.77 ms
219.158.107.2 AS4837 [CU169-BACKBONE] ** 山东省 chinaunicom.cn 联通
148.75 ms / * ms
10 219.158.6.14 AS4837 [CU169-BACKBONE] ** 山东省 chinaunicom.cn 联通
146.75 ms
219.158.8.254 AS4837 [CU169-BACKBONE] ** 吉林省 chinaunicom.cn 联通
151.76 ms / * ms
11 *
12 221.183.120.209 AS9808 [CMNET] ** 山东省 chinamobile.com 移动
177.75 ms / * ms / * ms
这里的 221.183.129.153 和 221.183.120.209 感觉分别是移动和联通的国内总路由之类的，ipip.net没给省份
[NextTrace API] prefered API IP - 104.26.9.231 - 1.05ms IP Geo Data Provider: LeoMoeAPI traceroute to 112.53.68.97, 30 hops max, 32 byte packets 1 38.47.116.254 AS979 美国 加利福尼亚州 洛杉矶 as979.net 18.71 ms / 102.45 ms / 13.32 ms 2 10.9.8.7 * [RFC1918] 局域网 0.58 ms / 1.23 ms / 0.70 ms 3 * 4 * 5 59.43.189.37 * [CN2-BackBone] ** 上海市 chinatelecom.cn 电信 127.14 ms / 126.87 ms / 127.21 ms 6 59.43.187.85 * [CN2-BackBone] ** 上海市 chinatelecom.cn 电信 128.10 ms / 228.71 ms / * ms 7 59.43.138.69 * [CN2-BackBone] ** 上海市 chinatelecom.cn 电信 128.78 ms / 132.48 ms / 140.93 ms 8 59.43.80.145 * [CN2-BackBone] ** 上海市 chinatelecom.cn 电信 132.86 ms / * ms / 233.98 ms 9 202.97.95.242 AS4134 [CHINANET-BB] ** 山东省 chinatelecom.com.cn 电信 153.10 ms / 153.09 ms / 153.06 ms 10 * 11 * 12 221.183.129.153 AS9808 [CMNET] ** 湖北省 chinamobile.com 移动 272.45 ms / 272.78 ms / * ms 13 * 14 211.137.196.54 AS24444 [CMNET] ** 山东省 临沂市 chinamobile.com 移动 178.63 ms / 179.01 ms / 178.65 ms 15 112.53.68.97 AS24444 [APNIC-AP] ** 山东省 临沂市 chinamobile.com 移动 178.27 ms / 178.25 ms / 178.21 ms MapTrace URL: https://api.leo.moe/tracemap/8d3c1c75-6bf9-50f9-bea2-819c6a68be57.html[NextTrace API] prefered API IP - 104.26.9.231 - 1.34ms IP Geo Data Provider: LeoMoeAPI traceroute to 112.53.68.97, 30 hops max, 32 byte packets 1 * 2 10.5.4.3 * [RFC1918] 局域网 1.37 ms / 2.65 ms 10.6.5.4 * [RFC1918] 局域网 2.96 ms 3 162.219.85.77 AS10099 [CUG-BACKBONE] 美国 加利福尼亚州 洛杉矶 chinaunicomglobal.com 联通 1.08 ms / 1.57 ms / 1.87 ms 4 203.160.75.218 AS10099 [CUG-BACKBONE] ** 上海市 chinaunicomglobal.com 联通 134.75 ms / 135.14 ms 162.219.85.1 AS10099 [CUG-BACKBONE] ** 上海市 chinaunicomglobal.com 联通 129.65 ms 5 218.105.2.89 AS9929 [CNC-BACKBONE] ** 上海市 chinaunicom.cn 联通 CUII 139.88 ms 218.105.2.93 AS9929 [CNC-BACKBONE] ** 上海市 chinaunicom.cn 联通 CUII 130.92 ms / 131.44 ms 6 218.105.2.150 AS9929 [CNC-BACKBONE] ** 上海市 chinaunicom.cn 联通 CUII 133.53 ms / 139.48 ms / 139.80 ms 7 219.158.32.1 AS4837 [CU169-BACKBONE] ** 上海市 chinaunicom.cn 联通 134.18 ms / 135.23 ms / 141.71 ms 8 * 9 219.158.118.138 AS4837 [CU169-BACKBONE] ** 北京市 chinaunicom.cn 联通 144.77 ms 219.158.107.2 AS4837 [CU169-BACKBONE] ** 山东省 chinaunicom.cn 联通 148.75 ms / * ms 10 219.158.6.14 AS4837 [CU169-BACKBONE] ** 山东省 chinaunicom.cn 联通 146.75 ms 219.158.8.254 AS4837 [CU169-BACKBONE] ** 吉林省 chinaunicom.cn 联通 151.76 ms / * ms 11 * 12 221.183.120.209 AS9808 [CMNET] ** 山东省 chinamobile.com 移动 177.75 ms / * ms / * ms这里的
221.183.129.153和221.183.120.209感觉分别是移动和联通的国内总路由之类的，ipip.net没给省份
同时 221.183.120.209 也在上海，也已一并更新。
NextTrace v1.1.2 2023-02-20T05:07:06Z 88e69f7
[NextTrace API] prefered API IP - 103.120.18.35 - 80.05ms
IP Geo Data Provider: LeoMoeAPI
traceroute to 183.146.104.244, 30 hops max, 32 byte packets
1 121.250.127.129 AS4538 ** 山东省 临沂市 cernet.edu.cn 教育网
_gateway 0.40 ms / 0.37 ms / 0.53 ms
2 192.168.2.3 * [RFC1918] 局域网
0.45 ms / 0.31 ms / 0.32 ms
3 *
4 112.53.68.97 AS24444 [APNIC-AP] ** 山东省 临沂市 chinamobile.com 移动
2.74 ms / 1.91 ms / 3.95 ms
5 223.99.17.69 AS24444 [CMNET] ** 山东省 临沂市 chinamobile.com 移动
2.80 ms / 2.98 ms / 2.05 ms
6 *
7 221.183.135.61 AS9808 [CMNET] ** 湖北省 chinamobile.com 移动
* ms / 16.47 ms / 16.17 ms
8 221.183.94.142 AS9808 [CMNET] ** 浙江省 chinamobile.com 移动
* ms / 18.29 ms / 20.96 ms
9 *
10 202.97.64.137 AS4134 [CHINANET-BB] ** 浙江省 chinatelecom.com.cn 电信
221.85 ms / * ms / * ms
11 61.130.42.62 AS4134 ** 浙江省 金华市 chinatelecom.com.cn 电信
23.63 ms / 26.28 ms / 23.47 ms
12 61.130.156.21 AS4134 ** 浙江省 金华市 chinatelecom.com.cn 电信
31.46 ms / 31.20 ms / 30.99 ms
13 183.146.104.244 AS4134 [APNIC-AP] ** 浙江省 金华市 chinatelecom.com.cn 电信
25.31 ms / 29.40 ms / 25.20 ms
MapTrace URL: https://api.leo.moe/tracemap/119f77af-f3f1-5e64-8729-3466ee05f171.html
这里的221.183.135.61应该不是湖北
NextTrace v1.1.2 2023-02-20T05:07:06Z 88e69f7
[NextTrace API] prefered API IP - 103.120.18.35 - 79.53ms
IP Geo Data Provider: LeoMoeAPI
traceroute to 183.146.104.244, 30 hops max, 32 byte packets
1 121.250.127.129 AS4538 ** 山东省 临沂市 cernet.edu.cn 教育网
_gateway 0.71 ms / 0.60 ms / 0.56 ms
2 192.168.2.3 * [RFC1918] 局域网
0.29 ms / 0.35 ms / 0.30 ms
3 *
4 192.168.100.1 * [RFC1918] 局域网
0.85 ms / 0.66 ms / 0.83 ms
5 211.86.45.202 AS4538 ** 山东省 济南市 cernet.edu.cn 教育网
6.02 ms / 5.85 ms / 5.82 ms
6 *
7 101.4.115.249 AS4538 [BJR-CERNET] ** 山东省 济南市 cernet.edu.cn 教育网
81.21 ms / * ms / * ms
8 101.4.115.33 AS4538 [BJR-CERNET] ** 广东省 深圳市 cernet.edu.cn 教育网
8.19 ms / 7.95 ms / 7.59 ms
9 101.4.117.29 AS4538 [BJR-CERNET] ** 上海市 cernet.edu.cn 教育网
25.36 ms / 25.07 ms / 25.06 ms
10 101.4.117.46 AS4538 [BJR-CERNET] ** 浙江省 杭州市 cernet.edu.cn 教育网
29.49 ms / 29.39 ms / 30.41 ms
11 101.4.117.41 AS4538 [BJR-CERNET] ** 福建省 厦门市 cernet.edu.cn 教育网
46.90 ms / 45.74 ms / 45.71 ms
12 101.4.112.45 AS4538 [BJR-CERNET] ** 广东省 广州市 cernet.edu.cn 教育网
66.16 ms / 55.86 ms / 55.89 ms
13 183.146.104.244 AS4134 [APNIC-AP] ** 浙江省 金华市 chinatelecom.com.cn 电信
27.00 ms / 26.62 ms / 26.62 ms
MapTrace URL: https://api.leo.moe/tracemap/2219831c-8b68-5c83-bc8c-0cf773e2ea94.html
这里101.4.117.41和101.4.112.45感觉也不对
这里59.43.247.62应该在上海
NextTrace v1.1.2 2023-02-20T05:07:06Z 88e69f7
[NextTrace API] prefered API IP - 103.120.18.35 - 176.78ms
IP Geo Data Provider: LeoMoeAPI
traceroute to 47.104.38.82, 30 hops max, 32 byte packets
1 121.250.127.129 AS4538 ** 山东省 临沂市 cernet.edu.cn 教育网
_gateway 0.58 ms / 0.53 ms / 0.57 ms
2 192.168.2.3 * [RFC1918] 局域网
0.36 ms / 0.47 ms / 0.83 ms
3 3.3.3.1 AS14618 美国 华盛顿州 西雅图 amazon.com
104.29 ms / 100.94 ms / * ms
4 112.53.68.97 AS24444 [APNIC-AP] ** 山东省 临沂市 chinamobile.com 移动
14.58 ms / 4.23 ms / 2.02 ms
5 223.99.17.69 AS24444 [CMNET] ** 山东省 临沂市 chinamobile.com 移动
2.05 ms / 2.24 ms / 3.58 ms
6 211.137.196.53 AS24444 [CMNET] ** 山东省 济南市 chinamobile.com 移动
5.13 ms / 4.81 ms / 5.49 ms
7 120.222.48.22 AS24444 [APNIC-AP] ** 山东省 济南市 chinamobile.com 移动
6.59 ms / 5.74 ms / 5.50 ms
8 120.192.93.194 AS24444 [APNIC-AP] ** 山东省 济南市 chinamobile.com 移动
6.97 ms / 5.24 ms / 5.22 ms
9 119.38.213.30 AS37963 [ALIBABA-CN] ** 上海市 alibabagroup.com
21.17 ms / 10.68 ms / 14.70 ms
10 103.41.143.53 * [HEYIXINXI-CN] 美国 加利福尼亚州 洛杉矶
10.43 ms / 10.37 ms / 10.26 ms
11 103.52.86.65 * [HEYIXINXI-CN] ** 北京市 合一信息技术（北京）有限公司
17.88 ms / 11.08 ms / 11.05 ms
12 *
13 *
14 47.104.38.82 AS37963 ** 山东省 青岛市 alibabagroup.com
11.05 ms / 10.88 ms / 10.88 ms这里103.41.143.53应该是国内的
[NextTrace API] prefered API IP - 104.26.8.231 - 3.26ms
IP Geo Data Provider: LeoMoeAPI
traceroute to 2001:67c:2b0::4, 30 hops max, 32 byte packets
1 2001:470:18:65e::1 * 局域网
tunnel859709.tunnel.tserv20.hkg1.ipv6.he.net 3.62 ms / 3.65 ms / 3.99 ms
2 *
3 *
4 *
5 *
6 *
7 *
8 2001:7f8::1a0b:0:1 * 局域网
decix.v6.eunetip.net 184.16 ms / 184.45 ms / 186.35 ms
9 2001:670:3:4:1::1 * 局域网
bbr1.esp1.fi.v6.eunetip.net 204.26 ms / 204.88 ms / 204.58 ms
10 2001:7f8:1d:44::72f8:1 * 局域网
elisa.transit.trex.fi 208.08 ms / 207.41 ms / 208.10 ms
11 2001:67c:2b0::4 * 局域网
resolver1.dns64.trex.fi 206.99 ms / 209.12 ms / 207.18 ms
MapTrace URL:NextTrace v1.1.2 2023-02-20T05:07:06Z 88e69f7
[NextTrace API] prefered API IP - 104.26.9.231 - 1.45ms
IP Geo Data Provider: LeoMoeAPI
traceroute to 2001:67c:2b0::4, 30 hops max, 32 byte packets
1 *
2 2607:f130::11 * 局域网
43.12 ms / 1.25 ms / 1.26 ms
3 2001:418:0:5000::674 * 局域网
ae-8.a03.lsanca07.us.bb.gin.ntt.net 0.83 ms / 0.92 ms / 0.74 ms
4 *
5 *
6 2001:550:0:1000::9a36:2da1 * 局域网
be2932.ccr32.phx01.atlas.cogentco.com * ms / * ms / 13.27 ms
7 *
8 *
9 *
10 *
11 *
12 *
13 2001:550:0:1000::9a36:251e * 局域网
be2846.rcr22.fra06.atlas.cogentco.com * ms / * ms / 154.77 ms
14 2001:978:2:42::5b:2 * 局域网
146.14 ms / 146.35 ms / 146.12 ms
15 2001:670:3:4:1::1 * 局域网
bbr1.esp1.fi.v6.eunetip.net 162.59 ms / 162.50 ms / 162.38 ms
16 2001:7f8:1d:44::72f8:1 * 局域网
elisa.transit.trex.fi 165.31 ms / 165.24 ms / 165.49 ms
17 2001:67c:2b0::4 * 局域网
resolver1.dns64.trex.fi 165.38 ms / 165.48 ms / 165.32 ms
MapTrace URL:NextTrace v1.1.2 2023-02-20T05:07:06Z 88e69f7
[NextTrace API] prefered API IP - 104.19.28.108 - 1.53ms
IP Geo Data Provider: LeoMoeAPI
traceroute to 2a03:7900:2:0:31:3:104:161, 30 hops max, 32 byte packets
1 2607:f130:0:18f::1 * 局域网
0.70 ms / 0.66 ms / 0.57 ms
2 2607:f130::11 * 局域网
* ms / 1.35 ms / 1.46 ms
3 2001:418:0:5000::674 * 局域网
ae-8.a03.lsanca07.us.bb.gin.ntt.net 0.75 ms / 1.00 ms / 0.95 ms
4 2001:418:0:2000::c6 * 局域网
ae-13.r25.lsanca07.us.bb.gin.ntt.net * ms / * ms / 203.41 ms
5 2001:418:0:2000::1bd * 局域网
ae-5.r25.asbnva02.us.bb.gin.ntt.net 61.77 ms / 61.62 ms / 62.68 ms
6 2001:418:0:2000::5d * 局域网
ae-7.r21.londen12.uk.bb.gin.ntt.net 130.51 ms / 130.81 ms / 130.23 ms
7 2001:728:0:2000::11d * 局域网
ae-1.r20.londen12.uk.bb.gin.ntt.net 136.14 ms / 135.00 ms / 135.30 ms
8 2001:728:0:2000::172 * 局域网
ae-11.r20.amstnl07.nl.bb.gin.ntt.net 135.35 ms / 135.15 ms / 135.22 ms
9 2001:728:0:2000::1ea * 局域网
ae-0.a01.amstnl07.nl.bb.gin.ntt.net 154.75 ms / 138.66 ms / 142.02 ms
10 2001:728:0:5000::7f2 * 局域网
133.69 ms / 133.75 ms / 133.62 ms
11 2a00:1188:4::7c0a * 局域网
a3510.tuxis.atom86.net 136.03 ms / 135.00 ms / 135.04 ms
12 2a03:7900:2:0:31:3:104:161 * 局域网
nat64.tuxis.net 135.52 ms / 135.00 ms / 135.32 ms
MapTrace URL:2607:f130::/32 是 Multacom 的
2001:418::/32 是 NTT 的
2001:550::/32 是 Cogent 的
2001:470::/32 是 HE 的
2a00:1188::/29 是 ATOM86 的
2a03:7900::/32 是 TUXIS 的
2001:7f8:1d::/48 和 2001:67c:2b0::/48 都是 TREX 的
（IPv6成局域网了？）
好像是API问题
Hello,
感谢您的提交，但是目前我们暂不会更新国内阿里云 IDC 的地理位置，一个封闭的 IDC 与我们的理念背道而驰。
Thanks!
Best Regards,
Leo Shen
这里
59.43.247.62应该在上海
已改正，感谢您的提交
Thanks!
Best Regards,
Leo Shen
202.97.96.234 不清楚在哪里，但一定不在香港。推测是在甘肃地带，可能是兰州？
（Update1）
一位位于兰州的朋友 Ping 了一下，基本上能确定就是甘肃兰州的IP了
这俩清华的 IP 如果可以的话，建议标注为
101.6.15.130 ** 北京市 清华大学开源软件镜像站 cernet.edu.cn 教育网
2402:f000:1:400::2 ** 北京市 清华大学开源软件镜像站 cernet.edu.cn 教育网
101.4.115.209 应该不在北京，应该是 CERNET 的骨干网，推测在辽宁或者吉林，但一定不会在北京。
这俩吉林大学开源镜像站的 IP 如果可以的话，建议标注为
2001:da8:b000:10::10 ** 吉林省 长春市 吉林大学开源镜像站 cernet.edu.cn 教育网
59.72.66.10 ** 吉林省 长春市 吉林大学开源镜像站 cernet.edu.cn 教育网
52.85.205.149 应该是洛杉矶的节点，根据 rDNS 的 lax50 可以推断出。
rDNS server-52-85-205-149.lax50.r.cloudfront.net
143.204.130.162 应该是旧金山的节点，根据 rDNS 的 sfo5 可以推断出。
rDNS server-143-204-130-162.sfo5.r.cloudfront.net
2600:9000:2139:2800:2:2f3f:2a40:21 应该是韩国的节点，可能在首尔？通过 P2 的响应头能看到 ICN51-C1
2001:506:9::3 美国 cogentco.com（地理位置不详，但肯定是cogentco的，软件只显示美国）
2600:3c0f:11:32::1 日本 东京都 品川区
2600:3c0f:11:32::2 日本 东京都 品川区
2600:3c0f:11:35::41 日本 东京都 品川区
2400:8902::f03c:93ff:fed3:1033 日本 东京都 品川区
2400:8902::f03c:93ff:fed3:1033 日本 东京都 品川区
204.68.252.109 日本 东京都 cogentco.com
202.97.92.58 应该是上海电信，从这个节点之后就进入联通的骨干网了，反正不可能是江苏电信
145.14.89.2 应该标注为 俄罗斯 莫斯科州 莫斯科 CT-PoP ，其用途应该与 145.14.89.1 相同，只不过前者负责国内段出发到国际段，后者负责国际段回程到国内段。
一些**省中华电信的 IPv6 被错误的标注为了**省教育网。
2001:b000:82:5:21:2255:1:2 AS9264 ** **省 hinet.net 中华电信
2001:b000:88:3:88:82:12:a AS9264 ** **省 hinet.net 中华电信
2001:b000:88:4:3031:4011:2:b AS9264 ** **省 hinet.net 中华电信
2001:b000:88:3:88:91:108:b AS9264 ** **省 hinet.net 中华电信
2001:b000:91:4:41:31:1:b AS9264 ** **省 hinet.net 中华电信
23 212.60.5.88 * [RU-BAXET] 捷克 布拉格
lg-prgrs.justhost.ru 336.21 ms / * ms / 339.93 ms
212.60.5.88 这个 IP 是 Justhost 莫斯科 Fiord
参考
192.210.206.0/24 AS36352 [RackNerd] 美国 加利福尼亚州 帕洛阿托 racknerd.com
现在 ColoCrossing 机房的这个段应该给 RackNerd 了，VirMach 不卖他家线路的 VPS 了。
现在 BGP.HE.NET 上的数据也更新了。
104.44.37.74 AS8075 [MSFT] 新加坡 microsoft.com
根据 rDNS 中的 sin30 能看出这个节点是位于新加坡的 Microsoft 节点
顺带我还有个问题，为什么会有一部分 IP 显示成类似 局域网 cloudflare.com 这种形式呢？
104.44.37.74 AS8075 [MSFT] 新加坡 microsoft.com
根据 rDNS 中的sin30能看出这个节点是位于新加坡的 Microsoft 节点
顺带我还有个问题，为什么会有一部分 IP 显示成类似
局域网 cloudflare.com这种形式呢？
Hello,
我们的自动化修正模块会根据rDNS自动修正骨干网的地理位置信息，因此如果您再次测试以后结果就可以看到已经被修正了。
Thanks
192.210.206.0/24 AS36352 [RackNerd] 美国 加利福尼亚州 帕洛阿托 racknerd.com
现在 ColoCrossing 机房的这个段应该给 RackNerd 了，VirMach 不卖他家线路的 VPS 了。
现在 BGP.HE.NET 上的数据也更新了。
Hello,
非常感谢，但是检查 AS36352 是 ColorCrossing 的 ASN，已经修改为 colorcrossing.com ，目前我们不按照 IP 段（而是ASN）存储域名信息，一个合格的主机商应该有自己的 ASN。
145.14.89.2应该标注为俄罗斯 莫斯科州 莫斯科 CT-PoP，其用途应该与145.14.89.1相同，只不过前者负责国内段出发到国际段，后者负责国际段回程到国内段。
Hello,
这是一个历史原因，在我们系统中该城市的格式模板发生过变动，目前已经修复。
Thanks
2001:506:9::3 美国 cogentco.com（地理位置不详，但肯定是cogentco的，软件只显示美国）
2600:3c0f:11:32::1 日本 东京都 品川区
2600:3c0f:11:32::2 日本 东京都 品川区
2600:3c0f:11:35::41 日本 东京都 品川区
2400:8902::f03c:93ff:fed3:1033 日本 东京都 品川区
2400:8902::f03c:93ff:fed3:1033 日本 东京都 品川区
204.68.252.109 日本 东京都 cogentco.com
Hello,
目前我们依旧在努力确定Linode的各区IP段位置信息，您的信息会帮助我们更好的确定Linode骨干网，谢谢。
202.97.30.221 ** 北京市 chinatelecom.com.cn 电信
202.97.75.130 ** 北京市 chinatelecom.com.cn 电信
221.183.49.130 ** 北京市 chinamobile.com 移动
本来我也以为是天津的节点，经过测试发现北京的延迟较低，大概率是北京市的节点。
后两个IP无论如何都不可能是江西省的或者海南省的节点，辽宁省到这些地区的延迟不可能这么低。
192.210.206.0/24 AS36352 [RackNerd] 美国 加利福尼亚州 帕洛阿托 racknerd.com
现在 ColoCrossing 机房的这个段应该给 RackNerd 了，VirMach 不卖他家线路的 VPS 了。
现在 BGP.HE.NET 上的数据也更新了。
Hello,
非常感谢，但是检查 AS36352 是 ColorCrossing 的 ASN，已经修改为 colorcrossing.com ，目前我们不按照 IP 段（而是ASN）存储域名信息，一个合格的主机商应该有自己的 ASN。
但目前我这边看，似乎还是 virmach.com，是因为 CDN 的缓存吗？
240e::1:21:61:5263 ** 江苏省 苏州市
240e:1a:4000:f112::3 ** 江苏省 苏州市
240e:1a:4000:1164::3 ** 江苏省 苏州市
追踪了一下自己家光猫的固定v6地址，发现最后几跳的v6地址的地理位置只显示**（包括我家光猫的v6地址，不方便直接放出来）
192.210.206.0/24 AS36352 [RackNerd] 美国 加利福尼亚州 帕洛阿托 racknerd.com
现在 ColoCrossing 机房的这个段应该给 RackNerd 了，VirMach 不卖他家线路的 VPS 了。
现在 BGP.HE.NET 上的数据也更新了。
Hello,
非常感谢，但是检查 AS36352 是 ColorCrossing 的 ASN，已经修改为 colorcrossing.com ，目前我们不按照 IP 段（而是ASN）存储域名信息，一个合格的主机商应该有自己的 ASN。但目前我这边看，似乎还是 virmach.com，是因为 CDN 的缓存吗？
CDN 无法缓存 ws 传输的内容，这是因为我们的API最近收到了大流量的暴力冲击，导致经常性资源耗尽，
因此我们在服务端做了大量的缓存来缓解这张情况，包括使用了 redis 来帮忙缓存这些ip的地理位置信息。
您可能需要等待若干天才能获得刷新后的数据。
谢谢