审核被网络原因拒到不能自理了= =

[xi_lin]

上周线上有比较紧急的 bug ，申请了加急审核，然后悲剧就开始了。

连续 5 次 reject ，都说是网络问题，附的截图是在 app 各种不同的地方弹出网络错误框。

看后台 log 审核账号的访问都显示正常返回。试着加大超时时限，无效。

以为是 IPv6 的问题，昨天搭了个 HE 的 tunnel proxy ，今天凌晨继续被拒。

找了个 SF 的小伙伴做测试，连通性并没有问题。

以前啥也不用改再要求审两遍总是能过的。但是这次有点惨 T_T

果爹真是虐我千百遍。

现在申请了 Apple Developer Technical Support 。

一会儿准备录个相表明本地 IPv6 测试没问题让审核看。

还有什么可以做的么？

今晚这个版本终于通过了！

今天这次提交做的事情是：
1. 把超时时间重新改小
2. 去掉了 IPv6 的 tunnel （反正加上也访问不到）
3. 录了小视频发 youtube 告诉他我在本地 IPv6 下测试过没问题
4. 告诉他我的服务器在中国，如果反应慢的话请再试试

另一个不同是今天的审核时间是 10 点前，之前都是夜里两三点

看了访问日志，这次的来访 IP 也不一样了。之前被拒的时候都是 17.200.11.44 ，今天是 65.199.22.137 。

还是吐槽大法保平安啊。

不知道申请的 Apple Developer Technical Support 还会不会联系我，回头再问问。

因为已经过审了所以 dts 只回复了一堆通用的步骤，附在这做参考吧

-------------------

Before discussing IPv6-specific issues, please be aware that not all App Review rejections that mention IPv6 are actually caused by IPv6 networking. The App Review rejection you ’ ve received indicates that:

* your app failed

* it was tested on an IPv6-only network

This does /not/ mean that the failure was specifically caused by that network. There are many other reasons why an app can work in your office but fail during App Review. At the end of this response you ’ ll find the standard answer we give to developers who are having problems reproducing an issue that occurs during App Review. You should work through these steps to make sure that you ’ ve not encountered some other issue that just happens to crop up during App Review.

If you ’ re convinced that this is an IPv6 issue, please read the “ Supporting IPv6-only Networks ” pinned post on DevForums.

<https://forums.developer.apple.com/message/136166#136166>;

This covers a number of points related to App Review ’ s IPv6 requirements. Specifically, read FAQ #6, which links to another document that has specific advice on how to debug IPv6 issues.

If this advice does not enable you to resolve the issue, please follow these steps:

1. On your Mac, set up the DNS64/NAT64 test network per the instructions referenced by FAQ #1 of the above-mentioned pinned post.

2. On your iOS device, join that test network.

3. On your Mac, start a packet trace. See QA1176 “ Getting a Packet Trace ” for information about how to take a packet trace.

<https://developer.apple.com/library/mac/#qa/qa1176/_index.html>;

IMPORTANT: Whatever packet trace tool you use, make sure it saves the packet trace in PCAP or PCAPNG format. The most common tools (`tcpdump` and Wireshark) do this by default.

4. On your iOS device, run your app and exercise its basic functionality, up to and including the point that App Review indicated that they had problems.

5. Stop the packet trace.

6. Use Apple Bug Reporter to create a bug report for investigating this issue.

<https://developer.apple.com/bug-reporting/>;

Consult the following checklist when filling out your bug report:

* When asked to select a product, choose Other > Other.

* Set the title of your bug report to “ App Review rejects App ID XXX for failing to work in the IPv6 network environment ”, replacing XXX with the App ID of your app.

* Indicate that you have tested your app in the DNS64/NAT64 test network.

* Attach the packet trace (from steps 3 through 5 above) to support that claim.

* If you have any thoughts as to which server is causing problems, put the DNS name of that server in your bug report.

For example, when App Review rejects an app they typically indicate the point at which it failed; if your app talks to some specific server at that point, mention it in your bug report.

7. Respond to this email with your bug number; DTS is tracking IPv6 issues and we ’ d like to associate your bug number with this email.

Finally, if you have code-level questions about IPv6 networking APIs on any of Apple ’ s platforms, please do get back in touch.

Different builds of the same code (for example, Debug vs. Release) can behave differently. When investigating issues reported only by App Review or customers, it ’ s important to ensure the build you are testing is the same build submitted to the App Store. Please read this entire email and the linked resources prior to following up with us: you ’ ll find helpful troubleshooting advice. If you do follow up with us, we will need certain information gathered during this troubleshooting phase.

Keep in mind, App Review is a “ real world ” environment. There may be varying networking situations, device configurations, usage patterns, and so on that affect your app. It ’ s safe to assume that issues reported by App Review have been confirmed by a normal user on normal device configurations, and reflect issues your customers would encounter, and are not unique to the App Review environment.

Important: DTS provides code-level support for iOS and OS X apps built using Xcode and Apple-provided frameworks and API. If your project is built with a third-party development environment or library, please contact its authors for support.

Steps to reproduce: If you are attempting to resolve an issue identified during app review and need additional information about how to reproduce the issue, use the Resolution Center or the Contact the App Review Team web form to follow up with App Review directly. DTS is unable to provide you steps to reproduce issues seen in App Review.

<https://developer.apple.com/appstore/contact/?topic=clarification>;

Test on the same version of iOS as the issue being reported: You will need to test your app on the same version of iOS that the issue was reported on; some issues only happen on specific versions of iOS.

Test the build you submit: If you are unable to reproduce an issue reported by App Review or customers, first verify you are testing the same build you submitted. Do this by building and testing your app using the process described in Technical Q&A QA1764 “ How to reproduce a crash or bug that only App Review or users are seeing ”.

You may also want to use TestFlight “ Internal Testers ” to test the version of the app being submitted.

<https://developer.apple.com/library/ios/qa/qa1764/_index.html>;

<https://developer.apple.com/testflight/>;

Debug deployed iOS apps: If you can reproduce the issue yourself after following the process in QA1764, you can diagnose the cause by using the techniques described in Technical Q&A QA1747 “ Debugging Deployed iOS Apps ” and others, like those described below.

<https://developer.apple.com/library/ios/qa/qa1747/_index.html>;

If you are unable to reproduce the reported issue after following QA1764, additional debugging will be needed. We ’ ve included a few helpful debugging techniques below; these should be considered starting points. During your debugging, you will need to consider all assumptions being made by your app and how those assumptions may be different in your customers ’ or App Review ’ s environment.

Test on multiple devices: Apps must be tested on actual devices, and on as many devices as possible, including Retina and non-Retina versions of iPad, iPhone, and iPod touch. Do not test only on the Simulator.
• Apps configured as “ Universal ” (in Deployment Info > Devices) must include complete iPad xibs or Storyboards with the proper and expected user interface.
• Apps that are iPhone only must still work on iPad devices in “ compatibility mode ” (also known as “ 2X mode ”).
• Issues reported on 64-bit devices (for example, iPhone 5s) need to be tested on 64-bit devices.

Symbolicate crash logs: Any crash logs you have will need to be symbolicated. Symbolicated crash logs replace memory addresses with human-readable function names and line numbers and can often point directly to the line of code that caused a crash. To learn how to symbolicate crash logs, see Technical Note TN2151 “ Understanding and Analyzing iOS Application Crash Reports ”.

<https://developer.apple.com/library/ios/technotes/tn2151/_index.html>;

Check differences in network connectivity: Use the “ Network Link Conditioner ” on your devices to test how your app behaves on a slow or unreliable internet connection. The behavior of the network that App Review or your customers use may be significantly different from the network you used during development. The Network Link Conditioner can be activated by navigating to Settings > Developer > Network Link Conditioner on your development device.

Test every language setting your app supports: Differences in localizations can cause different resources to be loaded, and for numbers and dates to be parsed or displayed differently. Remember to test each language setting on each device also.

Test data “ edge cases ”: Make sure you ’ ve tested app behavior when there are no Contacts, no photos in the Camera Roll, no Facebook friends, no Twitter followers and so on. Conversely, also check for a large number of contacts, photos and so on.

Use the Developer Forum: If you are unable to narrow the issue to a specific area of code or cannot reproduce the issue, you may want to consider posting your question to the Apple Developer Forums first, which is free and peer supported. Other developers may have seen similar issues, or have suggestions that can help you narrow the issue further.

<https://forums.developer.apple.com>;

Still unable to reproduce the reported issue? If you remain unable to reproduce the issue after following all of the previous suggestions, respond to this message and include the following:

1. The build UUID of the app you are testing. To find the build UUID of an IPA file, see Step 2 in Technical Q&A QA1765 “ How to Match a Crash Report to a Build ” (you do not need a crash log to follow this process).

<https://developer.apple.com/library/ios/qa/qa1765/_index.html#//apple_ref/doc/uid/DTS40012196-CH1-2__FIND_THE_BUILD_UUID_OF_AN_APP_BINARY>;

2. Fully symbolicated crash logs (if it ’ s a crashing issue). To learn how to symbolicate crash logs, see Technical Note TN2151 “ Understanding and Analyzing iOS Application Crash Reports ”.

<https://developer.apple.com/library/ios/technotes/tn2151/_index.html>;

3. Full details about the issue.

4. The troubleshooting and debugging steps you ’ ve taken to identify and resolve the issue.

Without these, we may not be able to provide further assistance.

[wwwjfy]

之前碰到一样的问题
苹果审核的地方到国内 AWS 好像线路有问题，后来在香港加了一个转发就好了

[xi_lin]

@wwwjfy 我们是阿里云
实在不行我也得加个海外转发了
你有加 IPv6 线路吗？

[IssacTseng]

在美国搭个服务器过审再切吧。

[paradoxs]

给网络错误弹窗干嘛? 请求失败直接终止刷新啊.

[xueyangkk]

嘿嘿 我们连拒 4 次 ~ 给你传授下 经验 ~· 咳咳 。。 老衲这里有一本 葵花宝典 可以给你修炼 ！~~~ 扯远了 ！

按老衲步骤做 你试试
1 ：排查资源 这里主要是云存储 图片 视频 音频 如果是放阿里云存储的话 注意 这里是 阿里云存储 ~ 那告诉你 申请 100 次也不会过 ~因为阿里云存储 不支持 IPV6 ~ 我们被拒 2 次 就是这个原因 后买了七牛北美云节点存储（解决）
2 ：排查 ECS 是否支持 ipv6 ~相关教程多如牛毛 自行谷歌 ~ 这个范围大太 教程很多 至于你说的录视频 那纯粹扯淡！ 苹果没时间看 ~ 我们提交 4 次 其中有一次 就录了 ~人家就一句话 打不开 就是打不开

按照你的描述应该就是我的问题 ~ 要是还解决不掉~ 可以找老衲 ~ 你要是个长腿妹子 可以免费 不是就。。。

[dorentus]

苹果的 IPv6 只要求在 NAT64 环境下面能通就行，根本就不需要服务器有 IPv6 地址。

只要你的 app 没有用一些底层的 IPv4 only 的 API ，或者直接往一个 IPv4 的地址发请求，都不会有 IPv6 的问题才对。

[laoyur]

楼上正解，哪需要你服务端弄什么 ipv6

[xi_lin]

@prinzchao 最多只能搭个转发。完全复制一套环境成本太大

[xi_lin]

@paradoxs 终止刷新是白页照样不会过审。。

[xi_lin]

@xueyangkk 我们用的是七牛。不过看截图都是接口没请求成功而不是资源不能加载。但看服务端 log 都是正确返回响应给苹果的 IP 了的。
昨天就是用个经典网络的 ECS 做跳板接了个 HE 的 IPv6 Tunnel ，反代真正的服务器，但是苹果还是没连上= =
我也觉得录视频没啥软用，只是死马当活马医

[xi_lin]

@dorentus
@laoyur
正常的时候是不需要支持 IPv6 啊，我一直是保证 NAT64 能通的。但这次拒的实在是太多次了，已经怀疑果家的 64 转换网关有问题了。。。

[zengfxios]

同样，被拒了两次，先以为是 ipv6 的问题，结果测试发现， ipv6 一点问题都没有！
后来猜测是超时导致的访问失败问题，录了个视频，发上去，审核就通过了！

[rogwan]

想问一下， ipv6 访问通不通，国内除了教育网内有 ipv6 地址可以测试，其他外网都是 ipv4 ，哪有什么方式可以试呢？

[rogwan]

@zengfxios 你是怎么搞到 ipv6 的 ip 去测试线路通不通的？

[rogwan]

以前的阿里云服务器禁用了 ipv6 ，要修改服务器的默认配置文件，才行。不知道阿里云现在新配置的环境有没有做调整，题主可以发工单咨询确认一下。

[xueyangkk]

http://ipv6-test.com/validate.php 这里输入你的域名 就可以测试 ~~

[xueyangkk]

@xi_lin 你这个思路就不对 假设你是苹果审核人员 使用的 IPV6 报网络错误 他完全可以认为 是你的 APP 或者服务器 压根不支持 IPV6 你先检查 你的服务器是否真正支持 IPV6 看下你的域名是否支持 ~ 一步一步的排查 ~

[kozora]

同被这个折磨了好多次

[cevincheung]

如果用 cloudflare 等类似的国际 CDN 呢

[xi_lin]

@rogwan HE 的 ipv6 tunnel 可以让你也有 ipv6 线路
手机装个 6Box 也可以

[xi_lin]

@xueyangkk 我现在把 HE 的 IPv6 反代撤了再试一次 IPv4
之前配好反代的时候 validate 前两项都是 pass 的

[xi_lin]

@cevincheung CDN 不是重点吧？我看审核的失败截图都是一副接口动态数据没回来的样子

[cevincheung]

@xi_lin #22 如果是 ipv6 的问题。 cloudflare 可解决啊。

[wwwjfy]

@xi_lin 同样弄了 HE 的 IPv6 ，然而没用
买了阿里云的香港节点，提交了就把海外 DNS 设到那里，审核过了再去掉，甚是蛋疼

[mornlight]

不需要服务端有 IPv6 地址， 6 楼理解是对的。
App Store 审核时用的网络不在大陆，我这里碰到的都是台湾，前几天也被拒了，网络不通导致页面是空白的，重新提交又过了。原因其实就是台湾到大陆的服务器连接可能出问题。
可以考虑非大陆用户解析到香港、台湾的代理服务器上去，审核过了再把 DNS 解析调回来。

[xi_lin]

@cevincheung CDN 能处理动态接口数据？

[xi_lin]

@wwwjfy 很醉。。你是在香港再架了一套后台？

[xi_lin]

@mornlight 我这边每次审核看 IP 都是美国总部
刚刚终于审核通过了= =
有一种后半夜网络会挂，前半夜能过的错觉

[cevincheung]

@xi_lin #26 其实就只个直接的反向代理……

[mornlight]

@xi_lin #28 你的 App 是不是除了中国区还在其他区上架了

[xi_lin]

@cevincheung 反代的话倒不算是纯 CDN 了。。我去考查一下，谢谢！

[xi_lin]

@mornlight 是的，所有区都上架了。中国区的就会是台湾？

[mornlight]

@xi_lin #32 我也不明白了，刚才问了一下我们的 App 也是提交所有区，但总是在台湾审核。

[cevincheung]

@xi_lin #31 通俗点就是 cloudflare 全球节点 dns 指向各自地区的节点 ip ，动态反向代理到你的服务器 ip 。

[mooczz]

解释一下就好了，和 review team 往来邮件好多次了

[xi_lin]

@cevincheung 我之前一直把 cloudflare 当成和七牛一样的静态 CDN

[xi_lin]

@mooczz 之前每次审核一两次打回也就算了，这次实在是心态有点要炸了

[bigbyto]

之前我们也被拒过很多次。恭喜楼主终于成功啦

[wwwjfy]

@xi_lin HAProxy 做了转发

[jialiangnull]

楼主你好,你这视频是怎么录的？ 怎么跟他证明 iPV6 把 DNS 截给他吗？

[auhah]

我们也遇到了这个问题。。。。。

然后在美国买了台云服务器给他们测试用

[xi_lin]

@bigbyto 难友啊~

[xi_lin]

@wwwjfy
@auhah
了解了。下次再搞不定就走这条路。。

[xi_lin]

@jialiangnull 我觉得视频不一定管用。。就是拍的时候进了下设置里的网络连接给他看网络信息
都是玄学

[jialiangnull]

我提交过去以后，他们显示都是空的列表，我现在怀疑是不是他们那边连接我们的服务器是有问题的。

[xi_lin]

@jialiangnull 可以先查一下自己服务器的日志，看接口访问纪录是什么样的
很大概率就是连不上自己服务器。。

[ntop]

@xi_lin 想问下楼主你最后的解决之道是不是就是让苹果那边多测试下？我爬完楼好像没有发现做了其它有用的改动。我也遇到这个问题，正在发愁。

[xi_lin]

@ntop 是的，没啥用。录个视频给审核看吧。