1. 手机app如何发起网络请求
手机APP在你点开使用时，软件会自动联入网络，除非断网了才会出现请求。你也可以用手机“设置”功能进行详细的设置APP软件的访问网络的选项。
2. 怎么打开手机app的上网权限
手机桌面，打开设置，蜂窝移动网络，无线局域网与蜂窝移动的应用，进入后就能看见手机里安装的所有APP了,选择你想赋予这个APP的权限。
3. app网络请求失败什么原因
这种现象是三个方面原因产生的：一：运营商（传输、交换网络的故障）的责任：运营商必须保证到用户的信号质量（带宽、误码率、信杂比、传输速率、信号电平、输入输出阻抗、信号的稳定度、输入输出阻抗的稳定性）符合国家标准）；具体电话：电信10000 网通10060二：用户（责任）下列因素会导致你目前的状态，如果经检测上述运营商没有问题，接下来，就是你用户自己的问题了；如果你不存在下列问题，你就可以直接打运营商电话，让运营商给你处运营商自己的相关事宜。★版权申明:本答案为和谐原创,任何人不得盗用!★三：网站的问题：1：网站服务器不稳定；2：网站的软件不稳定；3：网站运行维护质量水平较低；不能及时的排除故障；例如：上其他网站很好，某一个网站特别差，这就是网站自身的问题，与运营商和用户都无任何关系。
4. 分析移动端APP的网络请求
为了方便，本文以 iOS 系统来进行演示。
移动操作系统中都有可以设定系统代理的设置，比如在 iOS 中可以通过 Settings->WLAN 看到很多 Networks，通过点击它们后面的 Info 图标来设置代理：
这样的话，所有的请求就会先到我们设置的代理服务器，然后才有代理转发给目标服务器。于是我们就有机会在代理服务器上获取到请求的内容。
这里我使用的代理服务器是 Charles ，在安装并打开了 Charles 之后，Charles 就已经在后台建立了一个代理服务了。我们可以通过 ifconfig 命令找到自己的局域网 IP，Charles 默认的代理端口是 8888 。现在像上面的截图那样，在移动端中进行配置以使用我们的 Charles 代理。
现在你可以在移动端发起一些网络请求，当然最好是 HTTP 的，因为我不清楚 Charles 是否支持其他的协议类型。为了方便，我们可以使用 Safari 打开一段网址，比如 http://news..com (注意目前只是 HTTP 的，关于如何操作 HTTPS 下面会讲到)。题外话，正如你所见的，网络的最常用的功能就是检查网络服务的连通情况，比如 ping .com ，哈。
如果不出意外，那么你会在 Charles 左边栏中看到类似下图的情况：
那么说明我们的配置已经工作了，如果你点击它们中的一个，右边的界面中就会显示对应的请求内容：
很好，Charles 已经为我们做了很多事，现在我们可以轻松的知道发生了哪些请求以及请求的内容了。
现在我们试一试在 safari 中输入 www..com ，我们知道网络在 www 子域中使用了 HTTPS，并且当发现用户使用的不是 HTTPS 访问此子域时，会自动的 redirect，于是我们到了 https://www..com 。
现在再来看看 Charles 中的情况，我们发现 https://www..com 前面多了一把小锁：
并且右边没有给出请求的内容，但是有一条提示 - 对于 SSL 代理需要进行额外的设置。
下面我就简单解释一下为什么对于 HTTPS 而言 Charles 就暂时罢工了。更加具体的内容，可以见我的这篇文章 非对称加密和数字证书 。
HTTPS 就是 HTTP over TLS，就是在原本的 HTTP 请求之前，客户端和服务器先进行 TLS 握手并建立一个 TLS 链接，然后在此链接之上进行 HTTP 协议的内容。这样就使得我们的明文请求变成加密的。但是这里还是有一个缺陷，就是 TLS 握手阶段是明文的，那么为了解决这种鸡生蛋蛋生鸡的问题，出现了证书 (Certificate) 和证书颁发机构 (Certificate Authority)。
于是在 TLS 握手阶段，多了一个校验证书的步骤，服务端会返回 CA 颁发给其的证书，而客户端对证书的真实性进行校验。由于现在的请求内容已经被加密，所以作为代理的 Charles 无法知道其中的内容，于是为了使得 Charles 可以解析 HTTPS 的内容，我们就必须协助其完成 Man-in-the-middle 攻击，攻击的对象就是我们自己。
攻击的方式很简单，在手机上安装上 Charles 的 CA 证书即可，所谓 CA 证书就是 CA 机构的证书，来证明 CA 机构的真实性，一些权威的 CA 机构的证书都是内置在我们的操作系统中的。现在我们在移动端上安装了 Charles 的 CA 证书之后，Charles 就变成了 CA 了，于是它就可以颁发一个伪造的证书来欺骗移动端中的应用。
如果你不想了解其中的原理的话，要实现这个攻击还是很简单的，Charles 也提供了很多的便利，按照下面的步骤就行了。
我们在 Charles 的菜单中找到 ：
点击一下就会看到：
在移动端的 safari 中输入地址 http://charlesproxy.com/getssl 后，跟着下面的截图来将 Charles 制作的 CA 证书安装到移动端中：
到目前为止，Charles 制作的 CA 证书已经安装到了你的移动端，如果你希望删除它的话，可以通过 Settings->General->Profile 来找到它并删除，另外如果你不信任 Charles 自制的 CA 证书的话，它也是支持你使用自己的 CA 证书的。
再回到 Charles 进行一些设置，添加一下 SSL 规则：
现在，再回到移动端，在 safari 中访问 www..com ，然后再看看 Charles 中的结果，你会发现：
现在我们已经可以解析来自移动端的 HTTPS 请求了。
暂时就先写这么多吧
5. 如何抓取 android app 的 http 请求
有人提到Fiddler，但是Fiddler是针对HTTP
有人提到设代理，但是Android并非所有App通讯都会像http请求乖乖的走代理，不是root不root的问题，ios同理
有裤洞人提到tcpmp，但是tcpmp不能实时看通讯过程
建议枣纯铅
下载 Wireshark ，支持800多种通讯协议
无线网卡建立虚拟AP
连接wifi，直接用wireshark抓凳好包，一切通讯尽收眼底
6. fiddler怎么抓app的请求
1、PC端安装Fiddler
下载地址：Fiddler.exe，下面是Fiddler的简单介绍：
Fiddler是强大且好用的Web调试工具之宏袭燃禅册一，它能记录客户端和服务器的http和https请求，允许你监视，设置断点，甚至修改输入输出数据，Fiddler包含了一个强大的基于事件脚本的子系统，并且能使用.net语言进行扩展，在web开发和调优中经常配合firebug使用。
Fiddler的运行机制其实就是本机上监听8888端口的HTTP代理。 对于PC端Fiddler启动的时候默认IE的代理设为了127.0.0.1:8888，而其他浏览器是需要手动设置的，所以如果需要监听PC端Chrome网络请求，将其代理改为127.0.0.1:8888就可以监听数据了，手机端按照下面的蔽虚设置即可完成整个系统的http代理。2、 配置PC端Fiddler和手机
(1) 配置Fiddler允许监听https
打开Fiddler菜单项Tools->Fiddler Options，选中decrypt https traffic和ignore server certificate errors两项，如下图：
fiddler https options
第一次会提示是否信任fiddler证书及安全提醒，选择yes，之后也可以在系统的证书管理中进行管理。(2) 配置Fiddler允许远程连接
如上图的菜单中点击connections，选中allow remote computers to connect，默认监听端口为8888，若被占用也可以设置，配置好后需要重启Fiddler，如下图：
(3) 配置手机端
Pc端命令行ipconfig查看Fiddler所在机器ip，本机ip为10.0.4.37
7. android中如何监听到其他应用的网络请求数据
目前android提供的工具没事，我们写工程都是自己写http请求，每次请求的时候打Log，记录请纯做求的url和参数。请求回来了，打log，记录回来的数据，记录数据银早的状态，数据的内容。 目前做搏衡只能这样。如果用模拟器的话，可以用vnStat或者CommView之类的监控电脑网卡的请求，间接的监控手机。一般开发用手机测试，这样就不行了。只能打log了
8. IOS怎么抓取网络请求包
好吧，苹果提供了命令行监控的方法，将iPhone连接到Mac电脑的USB，输神悔入特定命令来监听iPhone的所有网络请求。
请求的内容会写入到一个文件，读取该文件即可获取所有网络请求。
而该文件需要特定工具才能打开，用WireShark，它再次派上了用场。
——————监控网络请求的步骤—————–
1.将iPhone连接到Mac电脑
2.从Xcode或者iTunes获得iPhone的UUID，一串32位的标示，类似0B6814B3-EB2F-5B85-929D-7C5C5SS8DB64
3.命令行输入rvictl -s [你的手机UUID标示]，打开Mac监听
4.命令行输入sudo tcpmp -i rv0 -n -s 0 -w mpFile.pcap tcp，开始向文件写入监控数据
结束监听时，ctrl+c关闭tcpmp进程。
关闭Mac监听，命令是 rvictl -v [你的手机UUID标示]
——————步骤结束———————–
以下是苹果官方文档
iOS Packet Tracing
iOS does not support packet tracing directly. However, if you’re developing for iOS you can take a packet trace of your app in a number of different ways:
If the problem you’re trying to debug occurs on Wi-Fi, you can put your iOS device on a test Wi-Fi network. See Wi-Fi Capture for details.
If your app uses HTTP, you can configure your iOS device to use a debugging HTTP proxy (such as Charles HTTP Proxy).
In iOS 5 and later you can use the remote virtual interface facility.
Remote Virtual Interface
iOS 5 added a remote virtual interface (RVI) facility that lets you use OS X packet trace programs to capture traces from an iOS device. The basic strategy is:
Connect your iOS device to your Mac via USB.
Set up an RVI for that device. This creates a virtual network interface on your Mac that represents the iOS device’s networking stack.
Run your OS X packet trace program, and point it at the RVI created in the previous step.
To set up an RVI, you should run the rvictl tool as shown below.
# First get the current list of 游带正interfaces.# First get the current list of interfaces. ifconfig -l
lo0 gif0 stf0 en0 en1 p2p0 fw0 ppp0 utun0
# Then run the tool with the UDID of 行袭the device.# Then run the tool with the UDID of the device. rvictl -s
Starting device [SUCCEEDED]
# Get the list of interfaces again, and you can see the new virtual# Get the list of interfaces again, and you can see the new virtual # network interface, rvi0, added by the previous command.
$ ifconfig -l
lo0 gif0 stf0 en0 en1 p2p0 fw0 ppp0 utun0 rvi0
Now that you know the name of the RVI, you can point your packet trace tool at it. For example, here’s how you might run tcpmp to take a packet trace from the RVI and write it to the file trace.pcap.
$ sudo tcpmp -i rvi0 -w trace.pcap
tcpmp: WARNING: rvi0: That device doesn’t support promiscuous mode
(BIOCPROMISC: Operation not supported on socket)
tcpmp: WARNING: rvi0: no IPv4 address assigned
tcpmp: verbose output suppressed, use -v or -vv for full protocol decode
listening on rvi0, link-type RAW (Raw IP), capture size 65535 bytes
When you’re done you can remove the RVI with the following command.
$ rvictl -x
Stopping device [SUCCEEDED]
Important: The RVI represents the entire networking stack of the iOS device; there’s no way to trace a specific interface on the device, or even learn which packets were transferred on which interface.