iOS群控，指的是一台电脑同时管多台 iPhone 的方案——集中查看画面、按组分发任务、统一回收结果，不用越狱也不用签名。
这篇要回答的是：iOS群控发出去没反应，先查设备还是先查号。
他给我讲那天的时候，自己都笑了。
早上九点，一台设备上的脚本跑完了，按记录是成功的，但内容没出来；他第一反应是账号出问题了，把号退出来换到另一台上重新跑。
新设备上也没出来；他又换回原来那台，还是不行。
到下午四点，他把那台机器的号换了两遍、重装了两次，最后发现是数据线松了，一路没连稳。
那天他一台机器都没发出去。
先判断是设备还是账号，再看状态栏
这两种问题的表现很像，处理方式完全不同，所以第一步不是动手，是判断。
判断的方法很土：拿同一台设备换一个正常在用的号跑一次，再拿同一个号换一台正常在用的设备跑一次。
设备换号能跑通、号换设备跑不通，问题在号；反过来，问题在设备。
两个都跑不通，才需要往上一层看，比如中控本身出了问题。
这一步只要三分钟，但能省掉一整天；上来就换号重装，等于什么都没排除，图什么呢？
先看状态栏，不用挨个点开。 判断之外，还有个更快的入口。
iOS群控 排查的第一步不是动手，是看状态。iOS中控 的状态栏右侧会直接显示当前的服务状态、设备个数、脚本运行状态。三十台设备，你先看这里，就知道是普遍性问题还是单台问题。
设备个数对不上的时候，那是连接层的问题，跟账号没关系，直接去查线和口。设备个数正常但脚本状态是停的，那就是脚本侧的事。
点运行状态能看到更细的，中控、桥接、AI Agent 各自的状态，还有重启和看日志的入口。多数时候问题在这儿就能定住方向。
按现象分：发不出去、要验证、登不上
第一种是跑完了但内容没出来。这类先去执行记录里看那一步的返回值，别急着换号；返回值里会写清是参数不对、超时还是别的。看清楚了再动。连哪一步错的都不知道，换号有什么用？
第二种是刚跑就报错。通常是脚本要点击的地方变了，比如平台改了版式，找图找不到。这种换号没用，得重新录一次。
第三种是设备根本没被识别。这是连接问题，先看线，再看接口，最后才看中控。把顺序搞反会浪费很多时间。
要重新验证的那种。 有一种表现是：脚本能跑，账号也在，但操作到某一步会弹出验证。
这种情况和前面几种不一样。它不一定是坏了，可能是这个号需要你本人确认一次。
我的做法是：遇到一次就先人工把它走完，不要用脚本反复试同一件事；反复试只会让这个号更难恢复，而且你会被卡在这一台上出不来了。
多账号运营里，一个号卡住不影响其他二十几个；先把它从当天的任务里摘出来，处理完再放回去。这是账号前期维护里最常见的动作之一。
登不上的时候，别连着试。 有的号会直接登不上。
这种情况下最多试两次。第一次失败之后停十分钟再试第二次，两次都不行就放着。
连着试五六次是没有意义的，你能看到的现象每次都一样，而每一次尝试都是一次新的异常记录。放两三天再看，很多时候它自己就正常了；要是还不行，那才需要找平台处理。
这条是我自己踩出来的，没有第二种更聪明的办法。
免越狱 的方案不动系统，所以设备本身的状态不会因为脚本而变。你在排查的时候可以把系统因素基本排除掉，专心看连接和账号这两层。
处理完留一笔，下次才不用从头猜
iOS自动化脚本 能留下执行记录，但判断的过程得你自己补。每处理完一次异常，记一行：什么时候、哪台设备、哪个号、什么现象、最后怎么好的。
这行字当时看着没用。三个月后再遇到一样的现象，你能直接翻到上次是怎么处理的，不用从头猜。
一天记一行，一个月也就三十行；真出事的时候，这三十行的价值比任何文档都高。
回到开头那个人。他现在遇到没反应的习惯是先看一眼状态栏，然后拿一台正常设备跑一次对照。
他说这个动作花三分钟，但让他少过了很多个那样的下午。
工具能给你状态和记录，判断哪一层出问题这件事，还是得你自己练；设备投屏 上看到的现象永远只是结果，不是原因。