使用Node.js应用调用Chaincode时无法连接到发现的Orderer问题求助

看起来你遇到的核心问题是：启用服务发现后，Peer的发现服务返回了Orderer的内部IP（172.31.42.206），但你的外部Node.js应用无法通过这个IP建立gRPC连接到Orderer——这也是为什么查询能成功（只和Peer交互），但调用失败（需要提交交易到Orderer）的原因。下面是针对性的解决方案：

1. 先排查网络连通性问题（AWS安全组） #

首先确认AWS安全组规则是否允许Node.js应用所在机器的IP访问Orderer VM的7050端口：

• 登录AWS控制台，找到Orderer对应的VM实例，查看其关联的安全组
• 添加入站规则：允许TCP 7050端口，来源设置为Node.js应用机器的公网IP（临时测试可设为0.0.0.0/0，生产环境请勿使用）
• 测试连通性：在Node.js机器上执行telnet 172.31.42.206 7050或nc -zv 172.31.42.206 7050，如果能连通说明网络没问题；如果不通，优先解决安全组/防火墙的拦截问题。

2. 验证Orderer TLS证书的SAN配置 #

因为你使用的是grpcs协议，TLS握手要求证书的**Subject Alternative Name（SAN）**必须包含你连接的地址（IP或域名均可）。如果发现服务返回的是Orderer的IP，但证书里只配置了域名（比如orderer.example.com），TLS握手会直接失败，导致连接超时：

• 检查Orderer的TLS证书：执行openssl x509 -in orderer-tls-cert.pem -text -noout查看证书内容，确认X509v3 Subject Alternative Name字段包含IP:172.31.42.206或对应的域名
• 如果未包含，需要重新生成Orderer的TLS证书：修改crypto-config.yaml中Orderer节点的hosts字段，添加该IP，再用cryptogen重新生成证书，替换Orderer VM上的证书并重启服务。

3. 显式在连接配置中定义Orderer节点 #

服务发现会优先使用连接配置中已定义的节点信息，而非动态返回的地址。你可以在连接配置文件中添加Orderer的完整配置，强制应用使用域名而非IP连接：

{ 
  "name": "test-network-org1", 
  "version": "1.0.0", 
  "client": { 
    "organization": "Org1", 
    "connection": { 
      "timeout": { 
        "peer": { 
          "endorser": "300" 
        },
        "orderer": "3000" // 增加Orderer的超时时间，适配跨VM连接的延迟
      } 
    } 
  }, 
  "organizations": { 
    "Org1": { 
      "mspid": "Org1MSP", 
      "peers": [ "peer0.org1.example.com" ], 
      "certificateAuthorities": [ "ca.org1.example.com" ],
      "orderers": [ "orderer.example.com" ] // 可选，将Orderer加入Org1的节点列表
    } 
  }, 
  "peers": { 
    "peer0.org1.example.com": { 
      "url": "grpcs://peer0.org1.example.com:7051", 
      "tlsCACerts": { 
        "pem": "-----BEGIN CERTIFICATE-----...-----END CERTIFICATE-----\n" 
      }, 
      "grpcOptions": { 
        "ssl-target-name-override": "peer0.org1.example.com", 
        "hostnameOverride": "peer0.org1.example.com" 
      } 
    } 
  },
  "orderers": {
    "orderer.example.com": {
      "url": "grpcs://orderer.example.com:7050",
      "tlsCACerts": {
        "pem": "-----BEGIN CERTIFICATE-----...-----END CERTIFICATE-----\n" // 填入Orderer的TLS根证书PEM内容
      },
      "grpcOptions": {
        "ssl-target-name-override": "orderer.example.com",
        "hostnameOverride": "orderer.example.com"
      }
    }
  }, 
  "certificateAuthorities": { 
    "ca.org1.example.com": { 
      "url": "https://ca.org1.example.com:7054", 
      "caName": "ca-org1", 
      "tlsCACerts": { 
        "pem": ["-----BEGIN CERTIFICATE-----...-----END CERTIFICATE-----\n"] 
      }, 
      "httpOptions": { 
        "verify": false 
      } 
    } 
  } 
}

添加后，应用会使用你在/etc/hosts中映射好的域名连接Orderer，不再依赖发现服务返回的IP。

4. 调整Peer的发现服务配置（可选） #

如果你希望发现服务直接返回Orderer的域名而非IP，可以修改Peer的配置：

• 在Peer VM上设置环境变量，将Orderer的IP映射为域名：

  export CORE_DISCOVERY_PEER_ADDR_MAPPING=172.31.42.206:7050=orderer.example.com:7050
  

• 重启Peer服务后，发现服务返回的Orderer地址会是域名，应用就能通过/etc/hosts的映射正常连接。

5. 用工具测试gRPC连接 #

可以用grpcurl工具直接验证从Node.js机器到Orderer的gRPC连接：

# 先将Orderer的TLS根证书保存为orderer-ca.pem
grpcurl -cacert orderer-ca.pem grpcs://orderer.example.com:7050 list

如果能返回Orderer的服务列表，说明连接正常；如果报错，可根据错误信息定位TLS证书或网络的具体问题。

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