Hyperledger Fabric多组织部署启动网络遇REQUEST_TIMEOUT错误求助

我之前在部署多组织Hyperledger Fabric + Composer环境时也碰到过一模一样的超时问题，下面是我总结的排查和解决步骤，你可以一步步尝试：

1. 检查所有Fabric容器的运行状态 #

首先确认整个网络的核心节点都在正常运行：

• 执行docker ps命令，查看所有Fabric相关容器（peer0.org1、peer0.org2、peer0.org3、orderer.example.com等）的状态是否都是Up
• 如果有容器退出，先执行docker logs <退出的容器名>查看错误原因，然后重新启动整个网络（比如用教程里的byfn脚本：./byfn.sh down再./byfn.sh up -s couchdb）

2. 延长命令超时时间 #

多组织网络启动需要更多时间同步和处理请求，默认的超时时间可能不够：

• 在你的composer network start命令末尾加上--timeout 300（设置为300秒，也就是5分钟），比如：

  composer network start -l "DEBUG" -c PeerAdmin@byfn-network-org1 -n block-aviation-network -V 0.0.1 -o endorsementPolicyFile=./tmp/composer/endorsement-policy.json -A SimonOrg1 -C SimonOrg1/admin-pub.pem -A SimonOrg2 -C SimonOrg2/admin-pub.pem -A SimonOrg3... --timeout 300
  

3. 验证Docker资源分配 #

Hyperledger Fabric多组织环境对内存要求较高，内存不足会导致peer节点响应缓慢甚至卡住：

• 打开Docker Desktop的设置，找到Resources选项，确保分配的内存至少为4GB（建议6GB以上），然后重启Docker

4. 检查背书策略文件的正确性 #

错误的背书策略可能导致peer节点无法处理请求，进而引发超时：

• 打开./tmp/composer/endorsement-policy.json，确认里面的MSP ID和你的网络配置完全一致（比如Org1MSP、Org2MSP，注意大小写和拼写）
• 比如一个正确的多Org背书策略示例：

  {
    "identities": [
      {
        "role": {
          "name": "member",
          "mspId": "Org1MSP"
        }
      },
      {
        "role": {
          "name": "member",
          "mspId": "Org2MSP"
        }
      },
      {
        "role": {
          "name": "member",
          "mspId": "Org3MSP"
        }
      }
    ],
    "policy": {
      "1-of": [
        {
          "signed-by": 0
        },
        {
          "signed-by": 1
        },
        {
          "signed-by": 2
        }
      ]
    }
  }
  

5. 确认PeerAdmin连接配置的完整性 #

你的PeerAdmin连接文件（PeerAdmin@byfn-network-org1）需要包含所有参与组织的peer节点信息：

• 找到连接文件的存储路径（通常在~/.composer/connection-profiles/byfn-network-org1/connection.json）
• 检查peers字段是否包含了org1、org2、org3的所有peer节点，并且地址和端口映射正确（比如grpcs://localhost:7051对应peer0.org1，grpcs://localhost:9051对应peer0.org2等）

6. 检查证书文件的路径和权限 #

确保你指定的admin公钥文件路径正确，并且当前用户有读取权限：

• 执行ls -l SimonOrg1/admin-pub.pem（替换为你的Org路径），确认文件存在且可读
• 如果用的是相对路径，确保当前工作目录和命令执行的目录一致，或者改用绝对路径

7. 查看Peer节点日志定位具体错误 #

如果以上步骤都没解决，查看peer节点的日志能帮你找到根源：

• 执行docker logs peer0.org1.example.com（替换为对应的peer容器名），搜索ERROR或timeout相关的日志条目，看是否有具体的错误提示（比如MSP配置错误、连接orderer失败等）

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