IceCodeNew
IceCodeNew
或者不查备案信息，去分析域名的 NS 服务器位置和解析到的 IP 结果也行，https://github.com/felixonmars/dnsmasq-china-list 好像就是这么做的。
> 也有一种情况，已经备案的网站没有一个服务器在中国，那么该不该放到 geolocation-cn 就需要讨论。 我从来不奉陪备案这种玩意儿所以不是非常清楚，但就我所知一旦服务器不在国内了备案会立刻失效（这一点我是看 v2ex 站的经历知道的），所以我觉得你说的这种情况可能不存在。
> 有很多域名是 IP 在美国，加上 www 泛域名后地址在中国，所以直接判断域名地理位置容易给出错误结论。 这就是为什么我觉得查备案信息是更好的办法。首先我觉得它实现起来比判断 NS 和 geoip 更简单，而且 `geolocation-cn` 本意就是只包含接入中国服务器的网站，这种情况下通过域名访问的一定是要先备案的。
> > 这就是为什么我觉得查备案信息是更好的办法。首先我觉得它实现起来比判断 NS 和 geoip 更简单，而且 `geolocation-cn` 本意就是只包含接入中国服务器的网站，这种情况下通过域名访问的一定是要先备案的。 > > 查备案的网站比直连 GitHub 都慢，除非有第三方可信的查询网站。 我看了下完全展开的域名，2k 行都不到，往一个略遥远的未来做估计——对 2400 条域名做备案信息查询，一天 24 小时，每 60 分钟里能查到 100 条域名的备案信息就行了 （更何况我们并不需要在 24 小时甚至更短的时间里查完，域名备案是个相当长时间有效的属性，合理安排好时间每天验证一部分也可以，保持在对 API 合理使用的范围内）
> > 我看了下完全展开的域名，2k 行都不到，往一个略遥远的未来做估计——对 2400 条域名做备案信息查询，一天 24 小时，每 60 分钟里能查到 100 条域名的备案信息就行了 > > 我个人希望这个 repo 纯粹一些，也就是单纯的收集域名，检测功能不要或只在 Action 里。而且即使是加入了检测的功能，也得等待其他成员去 review。 没有问题，我的打算是另起一个分支，在那个分支里自动剔除域名后，用 GitHub API 发起 PR，这样一定要经过成员 review，一个域名才会被认定失效并真正被移除。
> > 没有问题，我的打算是另起一个分支，在那个分支里自动剔除域名后，用 GitHub API 发起 PR，这样一定要经过成员 review，一个域名才会被认定失效并真正被移除。 > > 我不是很明白前者的**自动剔除**和后者的**移除**。另外按照现在的活跃程度，可以暂时 delay。 哦，**自动剔除**是说在新的分支里 `geolocation-cn` 文件是由域名校验程序自动更新的。 然后这个被修改后的 `geolocation-cn` 文件被拿去提了 PR，经过成员 review，合并入 master 分支以后，不就是从 master 分支真正**移除**这个域名了吗。
Fix #398
> 用``` block ```呢 ? > > 因为有个网站叫 gfw ，并且存在伊朗的墙 可以，标签名称只是沿用 #390 的例子而已 但是换了标签名称还是没有解决问题。
> 这样写 > > ``` > full:services.googleapis.cn @cn @gfw > ``` > > 我个人跑了一下代码没发现这样写会有什么问题，可以再重新测试一下看看。 我主要是担心万一有解析实现比较有问题，把 `@block` 放在前面也许会比较好。总之这个顺序没啥区别吧，那现在这样不也可以么？ 然后关于 `@gfw` 的问题，上面有建议了，我也觉得换成 `@block` 比较好。出于谨慎（毕竟其他国家也可能有需要做 blocklist 的需要），我决定用 `blockbycn` 来标记。
我觉得我这个倡议不利于执行的一点在于目前 `main.go` 域名去重的能力非常羸弱——算了实话说吧，我觉得就是没有（ 我参与贡献的另外几个类似的项目，有 dnscrypt-proxy 下的域名黑名单，也有 [@felixonmars/dnsmasq-china-list](https://github.com/felixonmars/dnsmasq-china-list)，还有 [@Loyalsoldier/v2ray-rules-dat](https://github.com/Loyalsoldier/v2ray-rules-dat) 在我看来这三者都很快实现了较完善的域名去重功能，而这一功能在本项目中发挥作用的场景包括不同分类下域名会有重叠的问题。 举例来说该项目已经有一个 netease 的分类数据，今天我再去做一个 category-mooc-cn 的分类数据，study.163.com 域名我是加还是不加？ 除了这样目前还没有规定下来的原则问题，这个例子里还在要求贡献者自己人脑去重一遍，很不友好，而且也违背了这个项目给域名分类的初衷。 那如果要把上述的几点都抓全，就势必得接受分类后的域名互相之间存在重叠的问题——我担心这个重叠以后会越发展越厉害，而 geosite.dat 无谓的肥大也许会影响匹配效率、肯定会影响更新用时、说不定会妨碍在单片机上玩 v2ray 的用户流畅体验。