pradt2/always-online-stun

# 始终在线：STUN 服务器    您是否曾经想过：*天啊，为什么没有一个定期更新、全面的公开可用 STUN 服务器列表呢？* **嗯，就是这个了。一个在线 STUN 服务器列表，每小时刷新一次。** ## 如何使用 将此链接 [valid_hosts.txt](https://raw.githubusercontent.com/pradt2/always-online-stun/master/valid_hosts.txt) 硬编码到您的应用程序中，并在需要最新在线 STUN 服务器列表时随时使用它。 或者，如果您不想依赖 DNS 解析，可以使用 [valid_ipv4s.txt](https://raw.githubusercontent.com/pradt2/always-online-stun/master/valid_ipv4s.txt) 获取 IPv4 地址，以及 [valid_ipv6s.txt](https://raw.githubusercontent.com/pradt2/always-online-stun/master/valid_ipv6s.txt) 获取 IPv6 地址。 ### 带地理定位的 JS 示例 ``` const GEO_LOC_URL = "https://raw.githubusercontent.com/pradt2/always-online-stun/master/geoip_cache.txt"; const IPV4_URL = "https://raw.githubusercontent.com/pradt2/always-online-stun/master/valid_ipv4s.txt"; const GEO_USER_URL = "https://geolocation-db.com/json/"; const geoLocs = await(await fetch(GEO_LOC_URL)).json(); const { latitude, longitude } = await(await fetch(GEO_USER_URL)).json(); const closestAddr = (await(await fetch(IPV4_URL)).text()).trim().split('\n') .map(addr => { const [stunLat, stunLon] = geoLocs[addr.split(':')[0]]; const dist = ((latitude - stunLat) ** 2 + (longitude - stunLon) ** 2 ) ** .5; return [addr, dist]; }).reduce(([addrA, distA], [addrB, distB]) => distA <= distB ? [addrA, distA] : [addrB, distB])[0]; console.log(closestAddr); // prints the IP:PORT of the closest STUN server ``` ## 常见问题 ### 但是硬编码链接很糟糕？！ 嗯，不完全是。对于那些本就不该被硬编码的链接进行硬编码，这很糟糕。 这里的情况不同。由于我建议用户硬编码指向这几个特定文件的链接，我会避免做任何可能导致链接失效的事情（例如，我不会更改文件名、仓库名或我的 GitHub 用户名等）。 ### 但我仍然对硬编码任何链接感到不舒服... 请随时创建一个 issue，让我们讨论您的具体需求。 ### 列表多久刷新一次？ 每小时一次，您可以在提交消息中看到上次检查的时间戳。 ### 服务器遵循哪些 RFC 规范？ `valid_nat_testing_*` 列表中的服务器应具备 NAT 检测和行为测试的能力。这些能力大致对应于 RFC5780（以及隐含的 RFC5389）。 要进入这些列表，服务器必须正确响应 RFC5389 `BINDING` 请求，并在响应中提供 `OTHER-ADDRESS` 属性。 `OTHER-ADDRESS` 属性的存在是符合规范的方式，用于表明一个 STUN 服务器可用于 NAT 行为测试。 _目前，没有对 NAT 行为测试能力进行实际验证。我们依赖 STUN 服务器维护者仅在他们的服务器支持 NAT 行为测试时才设置 `OTHER-ADDRESS` 属性。_ _如果这对您来说是个问题（即您需要更强的保证），请打开一个 issue。_ 其他 `valid_*` 列表包含仅具备 NAT 检测能力的服务器。这些列表要大得多，因为只有一小部分服务器被配置为提供完整的 NAT 测试能力。 要进入这些列表，服务器必须正确响应 RFC5389 `BINDING` 请求。 ### 测试了哪些 IP 版本和传输协议？ IP 版本 4 和 6。UDP 和 TCP。 ### 我注意到列表在每次检查时都会被打乱。为什么？ 懒惰/不考虑周全的开发者往往只抓取列表中最上面的链接（而且说实话，我们能怪他们吗？）。 通过打乱列表，我确保我们不会最终一直向同一个主机发送请求。 ### 检查哪些服务器，以及我如何添加更多公开可用的服务器？ 列表在 `candidates.txt` 中。欢迎创建 PR 添加更多服务器，或者只是打开一个 issue 并在那里列出它们。 ### 我的服务器在你的列表上，我不喜欢。我该怎么办？ 打开一个 issue，它将在 24 小时内从自动化检查中移除。

标签：CMS安全, IPv4, IPv6, JavaScript, NAT穿越, PowerShell, STUN协议, WebRTC, 在线服务, 地理定位, 定期更新, 实时通信, 开源, 数据可视化, 服务器列表, 网络基础设施, 网络技术, 软件开发安全, 通知系统