Composer v1.1启动业务网络应用时出现REQUEST_TIMEOUT超时错误

我之前在Composer v1.1环境里踩过一模一样的坑，折腾了好几天才捋清楚，给你分享几个亲测有效的排查和解决方向：

核心问题很明确：你的链码sre-frontend-app:0.0.1在节点peer0.org1.example.com启动时，触发了默认的5分钟超时限制，导致启动失败，进而引发后续的endorser simulateProposal错误（这个是连锁反应，解决了超时问题它自然会消失）。

1. 先调大链码启动超时参数 #

Fabric peer节点默认的链码启动超时是300秒（5分钟），如果你的链码初始化逻辑复杂或者节点资源吃紧，这个时间可能不够：

• 找到peer节点的core.yaml配置文件
• 定位到chaincode.launchtimeout配置项，把值从300s调高到600s甚至更久（根据实际情况调整）
• 重启peer节点，记得清理之前残留的链码容器：docker rm -f $(docker ps -aq --filter name=dev-peer0.org1.example.com-sre-frontend-app-0.0.1)
• 重新尝试启动业务网络

2. 排查链码自身的初始化逻辑 #

超时大概率和链码启动时的初始化操作有关，你得检查：

• 链码的Init方法或者beforeTransaction这类前置钩子函数里，有没有耗时很长的操作？比如批量初始化大量数据、同步调用外部API、复杂的计算逻辑
• 如果有这类操作，尽量优化：比如把批量数据初始化改成异步执行，或者把非必要的外部依赖改成懒加载
• 可以用composer network start -v命令启动，开启 verbose 模式，看日志里具体卡在哪个步骤

3. 检查peer节点的资源瓶颈 #

资源不足是链码启动慢的常见原因：

• 登录peer节点，用top或者htop看CPU、内存使用率，如果持续超过80%，说明资源不够，得扩容或者杀掉占用资源的无关进程
• 检查磁盘IO，用iostat看看读写速度，如果磁盘慢，也会拖慢链码的加载和启动
• 可以调整链码容器的资源限制，在core.yaml里找chaincode相关的资源配置，适当调高CPU和内存配额

4. 验证版本兼容性 #

Composer和Fabric的版本匹配很重要，v1.1的Composer最好对应v1.1.x的Fabric版本：

• 如果你的Fabric版本是v1.2或更高，可能会有兼容性问题，建议回退到匹配的Fabric版本
• 重新部署Fabric环境后，再重新安装、启动链码

5. 深挖日志细节 #

你提到的endorser simulateProposal错误后面有省略号[...]，一定要把这部分内容找出来，里面可能有更具体的线索——比如链码容器启动失败、权限不足、依赖缺失等，这些都能帮你更快定位问题。

最后提醒一句：每次修改配置后，一定要确保peer节点完全重启，别只做热重载，否则配置可能不生效。

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