Linux 下 Vite 开发服务器请求一直卡住怎么排查【免费下载链接】viteNext generation frontend tooling. Its fast!项目地址: https://gitcode.com/GitHub_Trending/vi/vite在 Linux 上运行 Vite 开发服务器时浏览器里的请求可能一直挂起、页面迟迟加载不出来而服务端也没有明显报错。Vite 官方文档把这种现象称为 Requests are stalled forever其给出的原因是Vite 不做完整打包浏览器会请求大量文件从而需要大量文件描述符一旦超过 Linux 的文件描述符限制或 inotify 限制请求就会卡住。这篇文章依据 Vite 仓库中 troubleshooting 文档 和 server 配置文档给出从检查限制、临时调大到持久化配置的完整排查路径。确认问题是否符合 Linux 文件限制导致的卡顿先确认两个前提再进入后面的操作步骤你运行 Vite 开发服务器的系统是 Linux该小节在文档中明确限定 If you are using Linux。现象是请求一直卡住而不是报错退出。如果终端直接抛出Error: ENOSPC: System limit for number of file watchers reached那是文件监听数超限的另一类问题见文末相关但不同的问题处理路径不同。满足这两点时按下面的顺序处理。第一步调大文件描述符限制ulimit文档给出的第一条解决方案是提高文件描述符file descriptor限制。以下命令直接来自文档# Check current limit $ ulimit -Sn # Change limit (temporary) $ ulimit -Sn 10000 # You might need to change the hard limit too # Restart your browser需要注意两点ulimit的修改是临时的只对当前 shell 会话生效。修改后要在同一个 shell 里或新开终端后重新设置启动 Vite 开发服务器。文档提醒可能需要同时修改 hard limit即ulimit -Sn设置软限制时可能还受硬限制约束如设置失败可检查ulimit -Hn。文档要求改完后重启浏览器因为浏览器持有的连接数上限是启动时继承的。第二步调大 inotify 相关限制sysctl文件描述符限制正常但请求仍卡住时文档的第二条方案是调大 inotify 相关的三个内核参数。以下命令同样来自文档# Check current limits $ sysctl fs.inotify # Change limits (temporary) $ sudo sysctl fs.inotify.max_queued_events16384 $ sudo sysctl fs.inotify.max_user_instances8192 $ sudo sysctl fs.inotify.max_user_watches524288说明这些命令需要sudo权限且同样标注为临时修改重启机器后失效。fs.inotify用于查看当前所有 inotify 相关限制值可作为调整前后的对照。上一步不生效时持久化文件描述符限制如果临时调整都无法解决文档给出的是持久化配置路径涉及修改系统配置并重启机器文档原文明确 Note that these settings persist but a restart is required方式一systemd 配置。在以下两个文件中添加一行未被注释的DefaultLimitNOFILE65536/etc/systemd/system.conf/etc/systemd/user.conf方式二Ubuntu 专用。文档说明在 Ubuntu 上可能需要改为向/etc/security/limits.conf添加* - nofile 65536这两种方式都需要 root 权限编辑系统文件且都要求重启后生效。修改前建议先备份原文件。VS Code Dev Container 场景请求看似卡住如果你的 Vite 开发服务器跑在 VS Code Dev Container 里文档指出请求看起来卡住可能并非文件限制问题而是 VS Code 端口转发特性不支持 IPv6文档引用了 VS Code 官方 issue 作为依据。解决方法是在vite.config.js等配置文件中将server.host设为127.0.0.1import { defineConfig } from vite export default defineConfig({ server: { host: 127.0.0.1, }, })server.host用于指定服务器监听的 IP 地址默认值是localhost。按文档说明localhost下 Node.js 的 DNS 解析顺序和浏览器实际使用的地址可能不一致Vite 监听到的地址和浏览器请求的地址对不上时请求也会异常显式指定127.0.0.1可以消除这种歧义。修改后重启开发服务器即可。如何判断已解决文档没有给出固定的判定日志验证方式是回到最初的观察点浏览器中之前一直挂起的页面请求能够完成、页面正常加载重启浏览器ulimit 方案要求后新请求不再长时间无响应。相关但不同的问题排查时注意区分以下相邻问题它们的处理路径不同ENOSPC: System limit for number of file watchers reached项目文件如图片、静态资源太多超过文件监听数限制时出现的报错而非请求静默卡住。文档给出的方案包括调大fs.inotify.max_user_watches、用server.watch.ignored排除文件多的目录或用server.watch.usePolling改用轮询文档提醒轮询更耗 CPU。网络请求停止加载且使用了自签名 SSL 证书Chrome 在使用自签名证书时会忽略所有缓存指令并重新加载内容而 Vite 依赖这些缓存指令文档建议改用受信任的证书。如果上述 Linux 文件限制相关步骤都不生效文档建议携带完整现象到 Vite 社区的 GitHub Discussions 或 Discord 的#help频道提问。【免费下载链接】viteNext generation frontend tooling. Its fast!项目地址: https://gitcode.com/GitHub_Trending/vi/vite创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Linux 下 Vite 开发服务器请求一直卡住怎么排查？
Linux 下 Vite 开发服务器请求一直卡住怎么排查【免费下载链接】viteNext generation frontend tooling. Its fast!项目地址: https://gitcode.com/GitHub_Trending/vi/vite在 Linux 上运行 Vite 开发服务器时浏览器里的请求可能一直挂起、页面迟迟加载不出来而服务端也没有明显报错。Vite 官方文档把这种现象称为 Requests are stalled forever其给出的原因是Vite 不做完整打包浏览器会请求大量文件从而需要大量文件描述符一旦超过 Linux 的文件描述符限制或 inotify 限制请求就会卡住。这篇文章依据 Vite 仓库中 troubleshooting 文档 和 server 配置文档给出从检查限制、临时调大到持久化配置的完整排查路径。确认问题是否符合 Linux 文件限制导致的卡顿先确认两个前提再进入后面的操作步骤你运行 Vite 开发服务器的系统是 Linux该小节在文档中明确限定 If you are using Linux。现象是请求一直卡住而不是报错退出。如果终端直接抛出Error: ENOSPC: System limit for number of file watchers reached那是文件监听数超限的另一类问题见文末相关但不同的问题处理路径不同。满足这两点时按下面的顺序处理。第一步调大文件描述符限制ulimit文档给出的第一条解决方案是提高文件描述符file descriptor限制。以下命令直接来自文档# Check current limit $ ulimit -Sn # Change limit (temporary) $ ulimit -Sn 10000 # You might need to change the hard limit too # Restart your browser需要注意两点ulimit的修改是临时的只对当前 shell 会话生效。修改后要在同一个 shell 里或新开终端后重新设置启动 Vite 开发服务器。文档提醒可能需要同时修改 hard limit即ulimit -Sn设置软限制时可能还受硬限制约束如设置失败可检查ulimit -Hn。文档要求改完后重启浏览器因为浏览器持有的连接数上限是启动时继承的。第二步调大 inotify 相关限制sysctl文件描述符限制正常但请求仍卡住时文档的第二条方案是调大 inotify 相关的三个内核参数。以下命令同样来自文档# Check current limits $ sysctl fs.inotify # Change limits (temporary) $ sudo sysctl fs.inotify.max_queued_events16384 $ sudo sysctl fs.inotify.max_user_instances8192 $ sudo sysctl fs.inotify.max_user_watches524288说明这些命令需要sudo权限且同样标注为临时修改重启机器后失效。fs.inotify用于查看当前所有 inotify 相关限制值可作为调整前后的对照。上一步不生效时持久化文件描述符限制如果临时调整都无法解决文档给出的是持久化配置路径涉及修改系统配置并重启机器文档原文明确 Note that these settings persist but a restart is required方式一systemd 配置。在以下两个文件中添加一行未被注释的DefaultLimitNOFILE65536/etc/systemd/system.conf/etc/systemd/user.conf方式二Ubuntu 专用。文档说明在 Ubuntu 上可能需要改为向/etc/security/limits.conf添加* - nofile 65536这两种方式都需要 root 权限编辑系统文件且都要求重启后生效。修改前建议先备份原文件。VS Code Dev Container 场景请求看似卡住如果你的 Vite 开发服务器跑在 VS Code Dev Container 里文档指出请求看起来卡住可能并非文件限制问题而是 VS Code 端口转发特性不支持 IPv6文档引用了 VS Code 官方 issue 作为依据。解决方法是在vite.config.js等配置文件中将server.host设为127.0.0.1import { defineConfig } from vite export default defineConfig({ server: { host: 127.0.0.1, }, })server.host用于指定服务器监听的 IP 地址默认值是localhost。按文档说明localhost下 Node.js 的 DNS 解析顺序和浏览器实际使用的地址可能不一致Vite 监听到的地址和浏览器请求的地址对不上时请求也会异常显式指定127.0.0.1可以消除这种歧义。修改后重启开发服务器即可。如何判断已解决文档没有给出固定的判定日志验证方式是回到最初的观察点浏览器中之前一直挂起的页面请求能够完成、页面正常加载重启浏览器ulimit 方案要求后新请求不再长时间无响应。相关但不同的问题排查时注意区分以下相邻问题它们的处理路径不同ENOSPC: System limit for number of file watchers reached项目文件如图片、静态资源太多超过文件监听数限制时出现的报错而非请求静默卡住。文档给出的方案包括调大fs.inotify.max_user_watches、用server.watch.ignored排除文件多的目录或用server.watch.usePolling改用轮询文档提醒轮询更耗 CPU。网络请求停止加载且使用了自签名 SSL 证书Chrome 在使用自签名证书时会忽略所有缓存指令并重新加载内容而 Vite 依赖这些缓存指令文档建议改用受信任的证书。如果上述 Linux 文件限制相关步骤都不生效文档建议携带完整现象到 Vite 社区的 GitHub Discussions 或 Discord 的#help频道提问。【免费下载链接】viteNext generation frontend tooling. Its fast!项目地址: https://gitcode.com/GitHub_Trending/vi/vite创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考