这个帖子讨论我们在App审核中遇到的一些常见的网络问题
并不是所有的审核被拒都和IPV6有关
App审核被拒你通常收到下面的提示
·你的App失败了，可能是登陆失败或者其他请求失败
·他是在IPV6-Only（纯IPV6环境）下测试
这个并不代表了你的应用审核失败和网络有着特殊的联系。有很多原因会导致在你的工作环境是正常的但是在App审核的时候表现的不正常。在苹果的文档QA1724How to reproduce bugs reported against App Store submissions描述了如何一步步的解决这个问题。
App在纯IPV6环境下审核
App在纯的IPV6网络环境下审核，但是这个网络是支持NAT64/DNS64的。你可以测试你的App在一个相近的网络环境下，比如一个基于NAT64/DNS64的网络共享环境。FAQ#1 Supporting IPv6-only Networks张贴了如何设置的指导。你必须在进行下一步之前先测试你的网络。
你所测试的网络并不和App审核时所用的网络一致。后面的章节会讨论到一些潜在的问题。
检查所有服务
当你升级完你的App支持IPV6以后，非常重要的一点就是考虑所有服务是不是都是可以访问的。这个可能不太好评估。一些App可能由于不同的功能实现获取了很多不同的服务（比如核心功能，次级功能，广告，分析等等）。此外，这可能不是很容易找到所有服务，比如：
服务的名字可能被隐藏在库代码中
服务的名字可能通过其他的网络请求反馈给你的App
对于HTTP和HTTPS,你的App可能开启一个对话服务，该服务被重定向到另一个服务。
DNS CNAME records 意味着可能服务有很多别名
一个非常简单方法就可以知道你App所用到所有服务，请看CFNetwork diagnostic log
确保打开你的网络诊断日志
在正常的情况下运行你的App
获取并过滤你的日志，来得到一个服务列表
重要：如果你的App运用的是高级网络API（任何基于CFSocketStream，包括了NSURLSession和NSURLConnection），这样是非常有效的方式。如果你使用的是低级的网络API（如BSD Sockets），他可能不会显示任何网络的行为，你必须手动的去检查这些代码。
IPV6连接性
这篇文章 Networking Overview中说道：
请注意，不像你的服务供应商的部署的DAT64/DNS64网络，网络共享的测试环境，总是会生成一个同步的IPV6地址，它并不能访问外部的纯IPv6服务器。
App审核的网络，和那些提供IPV6到IPV6访问的供应商部署的是一样。因此，如果你的服务器支持IPV6访问的话，那你的App就可以直接可以建立对话，不需要进行NAT64的转换。
总的来说，这是一件好事，但是如果你的服务器声称支持IPV6，但是IPV6又不可用，可能是下面几种情况导致
DNS名字是错误的
DNS是正确的，但是并没有监听IPV6
开启了监听IPV6的服务，但是通过IPV6的请求失败
接下来的章节我们会依次讨论这些点
IPV6的DNS问题
检查IPV6连接性第一步要做检查你的DNS是不是对你的域名做出正确的解析。你可以使用dig命令行，下面是IPV6正常连接的一种情形
注意：dig是访问DNS域名服务器一个比较方便的工具。它并不是访问系统的DNS解析，而是直接访问DNS服务器。在这些例子中我使用了+nocmd和+nostats 参数来最小化文本输出，参数AAAA是来询问IPV6地址记录
正如你所看到的。服务器返回了一个NOERROR的状态（第三行）而且，Answer Section包含了一个IPV6的地址。这样表示服务器支持IPV6。
相反，如果没有显示当AAAA记录不存在的时候，会显示下面的内容
注意，状态还是NOERROR，但是却没有Answer Section。这表示服务器仅支持IPV4。如果是这种情况，你可以跳过下面的一些章节（直接跳到常见DNS问题章节），因为你的所有连接总是会通过NAT64转化。
但是如果你出现了这种情况
这种情况状态是SERVFAIL，这表示你的DNS服务器是有问题的而不是缺少AAAA这条记录。如果你的DNS服务器返回这条错误状态，可能是由于DNS64/NAT64网络导致的。
注意：在DNS64文中的Section 5.1.2 of RFC 6147，提到一个NAT64/DNS64网关，对待SERVFAIL需要和当你请求AAAA记录返回NOERROR是同等对待，但是苹果审核的网关目前没有执行这个要求。
另外一种情况
同样，关键的信息在第三行，NXDOMAIN的状态表示并没有这个名字的任何形式的记录。照理来说你应该是看不到这种情况的，因为服务器必须含有一个IPV4的地址记录。一些DNS服务器尽管有一个有效的A的记录，但是被询问到是否有AAAA记录的时候就会返回这个错误。这是个Bug就好像你的DNS服务器会导致IPV6的客户端产生问题，是因为DNS64/NAT64的网关需要在DNS服务器的存在相应的关键字：在查询AAAA返回一个NXDOMAIN的结果，意味着也没有A这样的记录，因此服务器名是无效的。
IPV6监听
如果你的服务器表面能支持IPV6，那么确保监听从DNS服务器上返回的IPV6地址。如果他是HTTP或者HTTPS的Web服务器，那么有很多基于Web的工具去测试它（比如： ipv6-test.com）。如果是一些其他类型的服务，那么你需要在一个原生的IPV6网络中去测试。
注意：当你测试一个Web服务器的时候，你必须确保你知道你的服务器可以通过HTTP/HTTPS访问，并且遵循正确的协议。
IPv6服务错误
这可能尽管你的服务器正确的用IPV6正确搭建了，但是通过IPV6访问却是失败的。如果你能获取到服务器的log信息，你就可以一步步去调试这些错误。如果你获取不到这些信息，那你必须在原生的IPV6网络中去测试。
常见的DNS问题
要想DNS64/NAT64正常工作，你的DNS服务器必须正确的搭建。一些很小的DNS服务器配置错误，就会导致在App的审核网络中，某些情况下出现错误，但是在其他的一些网络中不出现，比如你自己搭建的网络共享的测试环境。
这里有一些基于Internetde 用来测试DNS的。很多工具都是基于来自The Internet Foundation In Sweden的DNSCheck code。如果你能下载并且运行这些代码最好，当然你可以运用这些在线工具来测试online tool
当你在检查DNS的时候，请注意下面的几点
DNS别名（CNAME记录）
域名和区域
下面的章节会详细的讲述这些点
正如前面提到的，DNS允许CNAME记录多个别名。如果你连接的名字是一个DNS的别名，而且资源和目标名字在不同的区域，你必须单独一个个去检查。你同样可以用dig来找到DNS的别名。举个例子，下面的内容显示了ftp.microsoft.com其实是ftp.microsoft.akadns.net的CNAME,那么他就会依次显示ftp.microsoft.akadns.net. 然后显示134.170.188.232。而另一个www.example.com就会直接显示93.184.216.34。
在ftp.microsoft.com的例子中，DNS的别名意味着你必须连接microsoft.com.的域名和akadns.net.的域名
域名和区域
一些DNS检查工具不会让你输入任意一个域名，相反的，他们会让你输入一个域名的顶部区域。比如：你不能检查www.example.com,但是你可以检查example.com。你可以通过SOA的方式，发现这个这个域名的头部。如果你没有发现这个域名的SOA记录，那么会从域名最前的一个标签，然后继续查找，直到找到为止。下面的内容展示了如果使用dig命令：
如果你知道该域名的头部，那么你可以使用任意的DNS检查工具。下面的例子，是我在我Mac电脑上运行DNSCheck open source，使用dnscheck命令行跑的检查DNS
注意，跑这个dnscheck并不是很简单，如果你只要测试少量的域名，你可以用这个更简单工具IIS’s online tool
著名的前缀
一些开发者尝试在IPV4地址上加一些比较知名的前缀合成一个IPV6的地址，这在很多情况下是不行的。你需要使用getaddrinfo或者一些更高级的API去获取这些地址，具体你可以参考Use System APIs to Synthesize IPv6 Addresses。如果你想知道更多，请关注Supporting IPv6-only NetworksFAQ #4里面的内容。
谢谢！