WSO2 ESB端点重启/重部署后静默失效（EI 6.1.1环境）

我来帮你一步步定位这个Endpoint部署后“形同虚设”的问题，结合你用的Windows Server 2012、JDK 1.8.0_121和EI 6.1.1 ESB Profile环境，从几个核心方向入手：

1. 先确认Endpoint的实际部署状态 #

• 登录ESB管理控制台（通常是https://<服务器IP>:9443/carbon），进入Service Catalog > Endpoints，搜索你部署的Endpoint名称，查看它的状态是否为Active。如果状态是Inactive或者完全搜不到，说明CAR包可能没被正确解析部署。
• 检查服务器上的CAR包部署路径：确认Endpoint的配置文件（*.xml）是否在repository/deployment/server/carbonapps/<你的CAR包名>/1.0.0/ESB-INF/endpoints目录下。路径不符合规范的话，ESB会忽略这个Endpoint配置。

2. 排查Endpoint配置的语法与逻辑问题 #

• 把你的Endpoint配置代码拉出来检查，重点看代理服务的地址、名称是否拼写正确，比如正确的内部调用Endpoint应该是这样的：

<endpoint xmlns="http://ws.apache.org/ns/synapse" name="InternalProxyEndpoint">
    <address uri="http://<ESB内网IP>:8280/services/你的代理服务名称"/>
</endpoint>

• 注意：调用同一ESB上的代理服务时，别用localhost作为地址，Windows Server环境下可能出现网络绑定异常，优先用ESB的内网IP。

3. 开启DEBUG级日志抓细节 #

默认日志级别可能没记录Endpoint的加载或调用细节，你可以调整日志配置：

• 进入管理控制台的Logging > Log Configuration，找到org.apache.synapse.endpoints和org.apache.synapse.deployers这两个日志器，把级别改成DEBUG。
• 重新部署CAR包，然后查看repository/logs/wso2carbon.log，搜索你的Endpoint名称，看是否有加载失败的提示（比如“Failed to deploy endpoint”）。
• 同时检查repository/logs/wso2-esb.log，这里会记录ESB的消息流转日志，能帮你确认请求是否真的到达了Endpoint。

4. 排查Windows Server的网络与权限问题 #

• 虽然是内网，但Windows防火墙可能拦截了ESB内部的请求。检查防火墙规则，确保ESB的服务端口（8280、9443等）允许内部通信。
• 运行ESB的系统账户是否有足够权限读取部署目录？权限不足会导致CAR包无法被正确加载。可以给repository/deployment/server/carbonapps目录添加系统账户的读写权限试试。

5. 确认API与Endpoint、代理服务的关联正确性 #

• 检查API中引用的Endpoint名称是否和部署的完全一致（大小写敏感！）。比如API里写的是endpoint key="OrderProxyEndpoint"，那部署的Endpoint名称必须完全匹配。
• 进入代理服务的配置页面，确认它的出站Endpoint配置正确，确保请求能从API→Endpoint→代理服务→后端系统完整流转。

如果以上步骤都排查完还是没找到问题，可以把Endpoint的完整配置代码、API的关键配置片段贴出来，这样能更精准定位问题。

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