在 Windows 上运行 Stash，代理是否可用，取决于后台服务、托盘界面、Clash YAML 配置文件、策略组和路由规则之间的配合。常见问题大致分两类：一类是stash节点超时，表现为连接迟迟得不到响应、页面加载卡住或代理链路中断；另一类是stash配置解析错误，表现为配置加载失败、策略组或规则不生效。两类问题有时同时出现：配置解析不完整，会让部分路由落到错误策略，进而引发超时。本文按“现象—查看—处理—复盘”的顺序，给出可操作的排查路径。
> 说明：Stash 的 Windows 版本通过后台服务和托盘界面管理 Clash YAML、策略组及路由；官方文档明确其兼容 Clash 配置标准，涵盖配置文件、规则、订阅、策略组、HTTP 引擎和脚本等主题。安装服务需要管理员权限。Windows 安装程序由 releases.stash.ws 提供。本站非官方，以下内容为排查思路整理，不替代官方文档。
一、先分清现象：是超时，还是解析错误
排查前先判断问题落在哪一层，避免把配置错误当成网络故障反复重试。
1. 观察托盘界面与后台服务的状态。 如果托盘显示服务未运行或反复重启，应先解决服务层问题，再谈节点。安装服务需要管理员权限，权限不足会导致服务注册不完整，表现为界面可用但代理不生效。
2. 确认超时的范围。 是全部节点超时，还是仅个别策略组、个别规则命中的目标超时。全局超时更像配置或服务问题；局部超时更像节点、路由或上游链路问题。
3. 区分“配置未加载”和“配置已加载但行为异常”。 前者通常与 stash配置解析错误有关，例如 YAML 缩进、字段类型、重复键、引用不存在的策略组；后者多与 stash路由规则顺序、策略组选择、规则集匹配有关。
4. 记录可复现路径。 记下触发超时的目标、当前选中的策略组、最近一次改动的配置项。没有复现路径的排查容易变成盲目切换节点。
注意事项： 不要用“换节点”掩盖配置问题。若解析错误存在，换多少节点都可能出现同样的超时表现。
二、查看配置：优先排除 stash配置解析错误
配置是 Clash YAML 标准文件，解析器对格式较严格。多数“莫名其妙”的 stash节点超时，根源在配置结构。
1. 查看 YAML 基本语法。 检查缩进是否统一使用空格、是否存在制表符、冒号后是否有空格、列表项层级是否正确。缩进错位会让某个策略组或规则被解析到错误层级，导致路由行为与预期不符。
2. 查看字段类型与必填项。 端口应为数字而非字符串；布尔值不要加引号；策略组名称、节点名称需与引用处完全一致，包括大小写和空格。名称不一致会让策略组引用失效，进而触发 stash配置解析错误。
3. 查看重复键与覆盖关系。 同一层级出现重复的键时，不同解析器行为可能不同，容易造成“改了没生效”。合并多份配置或手工追加订阅内容时尤其要检查。
4. 查看订阅与本地修改的边界。 stash下载问题常出现在订阅更新环节：下载不完整、内容被截断、编码异常，都会让配置在解析阶段失败。若使用订阅，先确认下载结果完整，再检查本地是否有手工覆盖导致结构冲突。
5. 查看策略组与规则的引用完整性。 规则中引用的策略组必须存在；策略组中引用的节点或子策略组也必须存在。缺失引用不一定直接报错，但会让匹配落到默认策略，表现为特定目标超时。
6. 查看路由规则顺序。 stash路由按规则顺序匹配，靠前的规则优先。把宽泛规则放在具体规则之前，会让本应走代理的流量走直连，或反之。排查时逐条确认规则的目标策略组是否符合预期。
注意事项： 修改配置前保留一份可用备份；每次只改一处并重新加载，避免多个变量同时变化导致无法定位。
三、处理超时：从服务、节点到路由逐层收敛
确认配置可正常解析后，再处理 stash节点超时。
1. 确认后台服务与托盘界面一致。 以管理员权限确认服务处于运行状态；若服务异常，先修复服务再测试代理。托盘界面的开关状态不等于服务实际状态，两者需分别查看。
2. 缩小超时范围。 固定一个目标，切换不同策略组观察结果。若仅某策略组超时，检查该组内节点与组类型；若所有组都超时，回到配置与服务层。
3. 检查节点本身的可达性。 节点超时可能来自节点侧：地址变更、认证失效、上游限流。此时应更新订阅或更换节点信息，而不是反复调整路由规则。
4. 检查 HTTP 引擎相关设置。 官方文档包含 HTTP 引擎主题，若配置中涉及相关参数，确认其取值与当前使用方式匹配。参数不匹配可能表现为连接建立后无响应，容易被误判为节点超时。
5. 检查脚本与规则集的加载。 脚本执行失败或规则集下载失败，会影响路由判定。若配置依赖脚本生成策略或规则，先确认脚本能正常执行，再观察超时是否消失。
6. 处理 stash下载问题。 订阅或规则集下载失败时，先确认网络可达性与下载完整性，再重新拉取。下载内容不完整会让配置解析失败，进而让代理退回默认行为，表现为间歇性超时。
注意事项： 排查期间不要同时更换订阅、修改规则和切换节点，否则无法判断哪一步起了作用。
四、复盘：把一次性修复变成可复用经验
问题解决后，做一次简短复盘，能显著降低复发概率。
1. 记录根因分类。 明确本次是服务权限、配置语法、引用缺失、路由顺序、下载完整性还是节点侧问题。分类清楚，下次遇到同类现象可直接跳到对应步骤。
2. 固化配置变更流程。 每次修改前备份，修改后先做语法与引用检查，再重新加载；订阅更新后检查下载完整性，避免把 stash下载问题带入解析阶段。
3. 建立最小可用配置。 保留一份节点少、规则简单的配置作为对照。出现 stash节点超时时，先用最小配置验证服务与节点，再逐步加回策略组和规则，快速定位引入问题的改动。
4. 区分官方与第三方信息。 Windows 安装程序由 releases.stash.ws 提供，配置标准以官方文档为准；本站非官方，第三方教程中的字段和写法需与官方标准查看后再使用。
5. 关注高频组合。 实践中，stash配置解析错误与 stash路由误配常同时出现：解析层级错位导致规则落到错误策略组，表现为特定目标超时。复盘时把这类组合单独记录，后续排查可优先验证。
注意事项： 不要长期依赖“能用就不动”的配置。订阅、规则集和节点信息都会变化，定期做一次解析与路由查看，比故障后被动排查更省时间。
综上，排查顺序应是：先看服务与托盘状态，再验证配置能否正确解析，然后按策略组与规则缩小超时范围，最后区分节点侧与下载侧问题。把每次修复归入“服务、配置、路由、下载、节点”五类，并保留最小对照配置，stash节点超时与 stash配置解析错误的定位效率会明显提升。