Clash 启动脚本报错怎么逐项排查

Clash 启动脚本报错时，最棘手的不是报错信息本身，而是它往往只给一个模糊的“Failed to start”或“Error: Invalid config”，甚至无任何输出，让人无法判断是配置问题、权限问题、依赖缺失还是路径错误。这种情况下，盲目重装或换工具只会掩盖真实根源。真正有效的排查必须从系统级日志、脚本执行流程、环境变量和配置文件结构入手，逐项验证每一环节是否正常。

第一步是确认脚本入口是否正确。检查你运行的命令是否指向了正确的启动脚本，比如 `./clash.sh` 或 `node index.js`，确保该文件具有可执行权限。在终端输入 `ls -l clash.sh` 查看权限位，若显示为 `-rw-r--r--`，需执行 `chmod +x clash.sh` 添加执行权限。如果脚本本身有语法错误，如缺少引号、括号不匹配，或调用了不存在的模块，运行时会立即崩溃但不会提示具体行号，此时应使用 `bash -n clash.sh` 进行语法检查，避免脚本执行前就中断。

第二步是查看实际输出日志。很多用户忽略的是，即使没有显式报错，脚本也可能将错误写入标准错误流（stderr）或日志文件。尝试用 `./clash.sh 2>&1 | tee clash.log` 将所有输出重定向到文件，再打开 `clash.log` 检查是否有“Cannot find module”, “EACCES”, “Permission denied”, “Invalid YAML format”等关键词。这些才是真正的线索。特别注意：若提示“Port already in use”，说明已有 Clash 进程在运行，需先用 `lsof -i :7890` 查找并终止旧进程。

第三步是验证配置文件路径与格式。脚本通常依赖一个 `config.yaml`，但路径可能被硬编码或通过环境变量读取。检查脚本中是否有类似 `CONFIG_PATH=${CONFIG_PATH:-./config.yaml}` 的设定，确认当前目录下是否存在该文件，且其内容符合 Clash 官方要求的 YAML 结构。可用在线工具如 [https://www.yamllint.com](https://www.yamllint.com) 验证格式，尤其注意缩进必须统一为两个空格，禁止使用 Tab。若配置中有自定义的代理规则或订阅链接，要确认链接是否有效，尤其是那些需要登录的私密订阅。

第四步是检查依赖环境。若脚本使用 Node.js，运行 `node -v` 和 `npm -v` 确认版本兼容性；若使用 Python，确认 `pyyaml` 是否安装。某些脚本会自动安装依赖，但网络受限时可能失败。此时应手动运行 `npm install` 或 `pip install pyyaml`，并在安装过程中观察是否有证书错误或连接超时。若使用 Docker，需确认镜像是否完整拉取，容器是否以正确用户身份运行。

最后，关于“简历该用 PDF 还是 Word 投递；PikPak 怎么批量下载一整个目录”这类看似无关的问题，其实都属于同一类逻辑：当工具行为异常时，表面现象只是结果，本质在于对执行流程的理解深度。简历投递选择格式，本质是评估接收方系统的兼容性；PikPak 批量下载，核心在于识别其接口是否支持目录级请求。同理，Clash 脚本报错，关键不在“改哪个参数”，而在“谁在什么时候读取了什么数据”。只有把每个环节当作独立子任务来验证，才能跳过猜测，直达真相。