[Bug] 点击openwrt里面的openclash插件,openwrt内核崩，导致瞬间重启

[Atomic994]

Pre-check / 提交前确认

• I have searched existing issues and did not find a duplicate. / 我已搜索现有 issue，确认不是重复问题。
• I have read README deployment and FAQ sections. / 我已阅读 README 的部署与 FAQ 部分。

Install Method / 部署方式

Docker Compose

Version / 版本

foru17/neko-master:1.3.4;foru17/clash-master:1.3.5

Environment / 运行环境

OS:windows
Chrome:chrome 145
proxy:nginx/nginx proxy manager

Steps to Reproduce / 复现步骤

主路由(openwrt)运行openclash，另一台esxi机器，在里面运行的虚拟机docker运行neko-master,
配置参数之后，在虚拟机里面用npm反代nekomaster的，一切都正常，可以获取信息，但是只要获取了一段时间之后，去访问主路由的openclash插件，只要一点击openwrt里面的openclash插件，openwrt马上重启；openwrt试过了kwrt固件25.12和immortal wrt24.10.5都可以复现，openclash是最新版本的。当刚刚装好nekomaster的时候，去openwrt里面点击openclash的时候，openwrt不会重启的，一般是等nekomaster拉一会儿数据之后再点击openclash就可以复现这个bug了。我查看https://v2ex.com/t/1191225 这个帖子，跟其中一个用户Midnight说得情况基本一致，应该是内核崩了导致openwrt重启。我的主路由配置很高，不存在什么不够内存的情况。然后我又在另一台vps上搭建nekomaster服务，同样可以复现bug。目前解决方法：在esxi里面新建多一个虚拟机，先装好nekomaster配置好连接到主路由opneclash，然后将这个虚拟机的dns服务器地址改成不是主路由，就是让这个虚拟机连接不了互联网，这样子配置之后，这个bug就没有出现了。这个只是一个折中方案，希望能修复这个bug

Expected Behavior / 预期行为

修复bug

Actual Behavior / 实际行为

修复bug

Logs and Screenshots / 日志与截图

Additional Context / 补充信息

No response

[foru17]

This is a very strange issue. I have been running Neko Master for over a month across various environments—including an N5105 machine, a mobile CPE (MT3600BE), and several cloud servers using both Agent and Direct modes—and I haven't encountered a single kernel crash.

For reference, my current OpenWrt setup is quite stable:

• Model: VMware Virtual Platform (N5105)
• Firmware: iStoreOS 24.10.1 (Kernel 6.6.86)
• OpenClash: Latest Mihomo kernel

Since Neko Master communicates as a "sidecar" via WebSocket, it shouldn't be able to trigger a kernel reboot directly. I suspect this might be an issue with how your specific OpenWrt build handles the network stack or connection limits. It's possible that once Neko Master starts pulling data, the active connections trigger a bug in the firmware's kernel when you try to open the OpenClash UI simultaneously.

The fact that your "DNS workaround" (preventing the VM from reaching the internet) fixes the issue suggests there might be a network loop or a specific conflict in how your firmware handles local traffic redirection. Even on my weaker hardware (like the ARM-based MT3600BE), it remains rock solid.

I'd recommend checking the system logs (dmesg) right before the crash if possible, as that might reveal the specific Kernel Panic reason.