我意识到已经有很多关于Stack Overflow的问题已经被苹果公司拒绝使用他们的iOS应用程序，因为它们不适用于仅支持IPv6的网络。
我已经检查了我的代码，以确保没有硬编码的IP地址（绝对没有），也没有使用旧的可达性（根本没有）或其他低级网络框架（我们只使用NSURLSession）。我已经通过我的机器上的NAT64测试网络，应用程序（似乎）工作正常。
这是一个Xamarin应用程序，它通过HTTPS（而不是其他网络连接）与API通信。
我发现的一些答案表明，此问题的解决方案需要对服务器进行配置更改。
所以我的问题很广泛，需要进行哪些配置更改？更具体地说，您是否需要域名上的AAAA记录？如果是这样，应该如何配置？
作为软件开发人员，我更多地解决这个问题，因此没有详细了解IPv6如何工作以及需要更改哪些服务器。
您的服务器不需要更改。 NAT64应该处理仅限IPv4服务器的转换，DNS64应该确保为主机名获取正确的地址。因此，当使用主机名而不是硬编码地址并且您使用IP版本中立的API时，它通常应该正常工作。
可能失败的一个案例是当人们试图更加符合Apple的政策并在他们的DNS区域中放置一些假/假/错误的AAAA记录时。这些实际上会阻止DNS64生成正确的记录，因为它认为服务器具有真正的IPv6并且不需要翻译服务。
MacOS内置的DNS64没有与互联网的“真正”IPv6连接，并且会忽略这些错误的AAAA记录，但真正的DNS64不会。因此，在这种情况下，您的本地测试似乎会起作用，但Apple会看到它失败。
我构建了一个测试工具，您可以使用它在https://nat64check.org/上检查具有真实DNS64和NAT64服务的网站。随意使用它。
虽然它不是强制性的，但如果您希望Web服务具有最佳可访问性，则建议您实际通过IPv6访问服务器并提供AAAA记录。这将使您的服务独立于NAT64和DNS64翻译服务，这将提高可靠性和性能。它还将改善具有IPv6的其他用户的功能，因为它允许他们绕过ISP现在需要部署的技巧来弥补IPv4地址的缺乏（如CGN，DS-Lite等）。
它还可以防止DNSSEC出现问题：NAT64需要生成“假”AAAA需要使服务通过IPv6工作，DNSSEC旨在防止任何人撒谎DNS记录。如果您提供真正的AAAA记录，则NAT64不需要撒谎且DNSSEC不受影响。
总结一下：最好的办法是让服务器通过IPv6访问，并在DNS中使用AAAA记录发布其地址。这将使每个人受益。但是不要发布假的AAAA记录（例如那些以::ffff:，2001:db8:，64:ff9b:，fc或fd开头的记录）。那些会伤害所有拥有IPv6的人，这些人现在已经相当多了。当您通过IPv6提供服务时，将其视为生产服务并正确执行。