iOS 应用上架，必须支持 IPv6 线路访问，填坑之路亲测

[iConnect]

曾经上架 appstore 被各种原因拒到吐血，本以为对苹果的套路早已烂熟于胸，套路嵌套路，防不胜防，这次载到阿里云上了。网络上各种教程没一个靠谱的（没办法，套路常新），还有人靠这个在淘宝上收钱的。这两天又填了一次这个坑，明确两点：

1、不用任何费用（购买教育网 ipv6 专线当然可行，但没必要）
2、苹果上架审核亲测可行。

文章带截图，不重发了，原文在这： https://qingqing.com/post/1021206/time

[Leafove]

支持 ipv6 是说你的应用在 ipv6 环境下也可用,而不是需要你的服务器处于 ipv6 下

[SourceMan]

然而你理解错了？
1#正解，这个支持应该是相当简单了，分享出一个 ipv6 的 SSID，手机连上去，APP 不崩溃就可以了

[elgae]

我要喷，我觉得不要把因为不读文档而没做对的事称为“坑”，显得自己有点 stupid。

[mornlight]

服务器可以仅支持 IPV4 的，你把方向搞错了。

[jasontse]

这篇文章完全是错的。只要你不硬编码 IPv4，利用好 DNS64，服务器完全不用去折腾 IPv6。

[iConnect]

@Leafove
@SourceMan
那你说说没有 IPv6 隧道代理，苹果的审核人员怎么连你的国内服务器？


@elgae
@mornlight
@jasontse

国内的服务器都没有 IPv6 地址，所有才有这个必要的。

[hongshaoyuancn]

挂个国外 vps 做反代

[jasontse]

@iConnect 苹果审核的环境并不是一个 IPv6 孤岛，它可以通过 NAT64 来访问到 IPv4 网络，你只要满足这种网络兼容环境就行了。

[jasontse]

简单来说你的这种「代理」其实苹果已经自备

[iConnect]

@jasontse 事实上并不行。

[mornlight]

@iConnect #6

- 为什么 App Store 关于 IPV6 的规则并不强制要求服务器支持 IPV6 地址访问？
- 因为国内绝大多数服务端都没有 IPV6 地址，他们的 App 也都好好的。

一个基本的逻辑推导。

更多的细节，可以参考其他人写的关于这条规则的经验总结。「网络上各种教程没一个靠谱的」更可能的原因是你运气不好或者方式不对。即使你完全符合要求，也有一定概率被这个原因拒掉。
当然，你的这个思路也是可以解决问题的。

[iConnect]

@mornlight - 因为国内绝大多数服务端都没有 IPV6 地址，他们的 App 也都好好的。

哪个公有云服务器有提供过 IPv6 地址吗？

有一点你可能没注意，以前的方案是针对经典网络的，对专有网络的 local 配置是不对的。

[jasontse]

你还是要学习一个，认真理解苹果的需求。
https://developer.apple.com/library/content/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html

[Leafove]

诶

[iConnect]

@jasontse

if you ’ re writing a server-side app or other low-level networking app, you need to make sure your socket code works correctly with both IPv4 and IPv6 addresses.

这个要怎么通？你今年有上架 server-side 应用实际能过审吗？

[azuis]

你没有理解苹果的意思。苹果的意思是只要在 NAT64 下面能通就行了。简而言之就是说只要没有 hard code IP 地址或者使用某些不兼容的库，都是能正常访问的。 别说国内了，国外 Azure GCE 也都没 IPv6 地址的。

[azuis]

苹果的那个回复只是个模板。之前提交的时候提供了错误的测试账号。 也说要检查 IPv6 问题，但是实际上只是测试账号问题，重新提交后即正常过审。

[damondev]

没必要啊

[jasontse]

@iConnect
这么说吧。假设你的服务器是 123.123.123.123 不支持 v6，然后域名是 example.com 没有 AAAA。
苹果的 NAT64 网络会通过以下流程来兼容：
当域名被 DNS 服务器解析，发现没有 AAAA 记录，会被「污染」一个 64:ff9b::123.123.123.123 （非严谨写法）。
这样原本没有 AAAA 的就凭空多了一个 AAAA。
你完全可以按照原生 v6 的方式去连接这个「捏造」的地址，因为 64:ff9b: 开头的全部指向一个可以透明代理到 v4 的服务器上。
剩下的就不用动了。

[iConnect]

@jasontse 我知道哇，理论上没有问题，我本地可访问的测试截图都提交去申诉了，就是不断的被驳回再驳回。

实际上 App 驳回之后，什么都没改，把隧道调通，就秒过了。