看起来你遇到的核心问题很明确——那两条调用wpa_cli的exec命令在桌面端Chrome能正常等待执行完成，但移动端Chrome的超时阈值更低，直接触发了请求失败。结合树莓派Zero W的性能瓶颈，以及你让wlan0同时承担客户端+虚拟AP的特殊场景，我整理几个实用的排查方向：

1. 先确认wpa_cli命令的实际执行耗时 #

树莓派Zero W的CPU性能本来就弱，再加上wlan0同时在做客户端连接和虚拟AP，wpa_cli scan_results这类涉及网卡扫描的命令，执行时间可能比单网卡场景长得多。你可以直接在树莓派终端手动执行这两条命令，看看实际需要多久：

time sudo /sbin/wpa_cli -i wlan0 list_networks
time sudo /sbin/wpa_cli -i wlan0 scan_results

如果执行时间超过3-5秒，那移动端Chrome大概率会触发超时（移动端浏览器的默认超时通常比桌面端短不少）。这种情况的优化方向：

• 把扫描操作改成异步执行：用AJAX后台获取扫描结果，不要让扫描阻塞整个页面加载
• 缓存扫描结果：比如每隔30秒自动更新一次缓存，不用每次页面加载都重新扫描

2. 检查PHP执行sudo的免密权限配置 #

虽然桌面端能正常运行，但有可能移动端访问时，PHP进程执行sudo的权限出现了隐性阻塞（比如不同请求环境导致sudo需要交互输入密码）。你需要确保www-data用户可以免密执行这两条wpa_cli命令：

1. 编辑sudoers文件：

sudo visudo

2. 在文件末尾添加一行（精准限定允许执行的命令，避免过度授权）：

www-data ALL=(ALL) NOPASSWD: /sbin/wpa_cli -i wlan0 list_networks, /sbin/wpa_cli -i wlan0 scan_results

3. 保存退出后，切换到www-data用户测试：

su - www-data -s /bin/bash
sudo /sbin/wpa_cli -i wlan0 list_networks

如果不需要输入密码就能正常输出结果，说明权限没问题；如果命令卡住，那就是权限配置导致exec一直等待输入，最终触发超时。

3. 排查双模式下的网卡资源冲突 #

当wlan0同时作为客户端连接WiFi，又通过hostapd创建uap0虚拟AP时，网卡的射频资源可能被抢占。执行wpa_cli的扫描或列表命令时，可能需要和hostapd抢资源，导致命令执行大幅延迟。你可以临时关闭hostapd服务，再测试移动端访问：

sudo systemctl stop hostapd

如果关闭后移动端能正常加载页面，那说明是双模式（客户端+AP）下的网卡资源冲突。这种情况的优化方向：

• 调整hostapd的配置：降低AP的信道优先级，或者设置扫描时暂时降低AP的发射功率
• 考虑更换支持双频的USB网卡，分开客户端和AP的频段（不过Zero W本身是单频的，这个方案成本略高）

4. 查看Nginx和PHP-FPM的日志找线索 #

超时问题的关键细节通常藏在日志里，你可以查看：

• Nginx错误日志：/var/log/nginx/error.log
• PHP-FPM错误日志：/var/log/php7.3-fpm.log
  看看有没有相关的超时、权限或者进程阻塞的报错信息，这些能帮你精准定位是命令执行卡住了，还是Web服务器层面的超时配置问题。

内容的提问来源于stack exchange，提问作者Kev Mic