永远在线：STUN服务器

你是否曾经想过：天哪，为什么没有一个定期更新的、全面的公开可用STUN服务器列表呢？

好了，这就是了。一个每小时更新的在线STUN服务器列表。

如何使用

将此链接valid_hosts.txt硬编码到你的应用程序中，并在需要获取最新的在线STUN服务器列表时使用它。

或者，如果你不想依赖DNS解析，可以使用valid_ipv4s.txt获取IPv4地址，使用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); // 打印最近的STUN服务器的IP:端口

常见问题

但是硬编码链接不是很糟糕吗？！

嗯，不完全是。硬编码那些从未打算被硬编码的链接是糟糕的。 这里的情况不同。既然我建议用户硬编码链接到这几个特定文件，我就会避免做任何可能使链接失效的事情（例如，我不会更改文件名、仓库名、我的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小时内从自动检查中移除。