这问题我之前帮好几个同事排查过，DataPower Web Service Proxy（WSP）在响应阶段忽略自定义Processing Rule、全走默认规则，大概率是这几个配置点没处理好：

1. 响应阶段的URL上下文不是你想的那个！ #

请求阶段的Match by URL是匹配客户端发来的原始请求URL，但响应阶段默认情况下，DataPower会用后端服务返回的响应URL（或者内部路由后的上下文路径）来做匹配，这和你预期的请求URL完全不是一回事，自然匹配不上自定义规则。

解决方法：
在请求阶段的Processing Rule里新增一个Set Variable动作，把原始请求的URI保存到全局上下文变量中：

• 变量来源选request/URI（对应客户端请求的路径）
• 目标变量设为var://service/original-request-uri（作用域选Service，确保整个事务周期都能访问）

然后在响应阶段的Match by URL动作里，不要用默认的“URL”选项，而是切换到Custom模式，用$var://service/original-request-uri作为匹配目标，再配置对应的路径规则。

2. WSP的响应路由模式没开规则处理 #

WSP默认的响应路由是Route Back——也就是把后端响应直接原路返回，根本不会经过你配置的响应Processing Rule的匹配逻辑。这是最容易踩的坑！

解决方法：
进入WSP的配置页面，找到Response Processing模块：

• 把Routing Type从Route Back改成Process with Rules
• 关联你已经配置好的响应Processing Rule集

这样响应才会进入规则匹配流程，而不是直接跳过。

3. Processing Rule的顺序和匹配优先级搞反了 #

如果你的默认Processing Rule排在了自定义规则的前面，DataPower会按顺序匹配，先命中默认规则就直接走了，根本不会检查后面的自定义规则。另外还要检查匹配条件的精度，比如用正则匹配时有没有多写/少写斜杠、有没有忽略参数等。

解决方法：

• 在响应Processing Rule集里，把自定义规则拖到默认规则的前面，确保优先匹配自定义规则
• 匹配条件尽量用精确正则，比如要匹配/api/user路径，就写^/api/user$，避免模糊匹配导致不命中

4. 上下文变量的作用域不对 #

如果请求阶段设置的变量作用域是Rule或者Transaction，可能到响应阶段就被销毁了，导致响应阶段拿不到原始URI。

解决方法：
在Set Variable动作里，把作用域明确设为Service，这样变量会在整个WSP服务的事务生命周期内保留。

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