<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Relay on Margrop Blog</title>
    <link>https://blog.margrop.net/en/tag/relay/</link>
    <description>Recent content in Relay on Margrop Blog</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-US</language>
    <lastBuildDate>Sun, 31 May 2026 08:00:00 +0800</lastBuildDate>
    <atom:link href="https://blog.margrop.net/en/tag/relay/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Why HermesAgent Would Not Reply in WeChat or WeCom: The Real Culprit Was a Local Relay With a 3-Second Timeout</title>
      <link>https://blog.margrop.net/en/post/hermesagent-wechat-wecom-relay-timeout-debugging/</link>
      <pubDate>Sun, 31 May 2026 08:00:00 +0800</pubDate>
      <guid>https://blog.margrop.net/en/post/hermesagent-wechat-wecom-relay-timeout-debugging/</guid>
      <description>The short version This incident looked like a model problem or a broken messaging channel, but the real failure happened one layer lower: my local relay cut the upstream request off after 3 seconds. That was fine for quick health checks, but it was wrong for real WeChat and WeCom turns, which often take longer to produce a complete answer from the NewAPI gateway. Once the relay disconnected too early, HermesAgent could only see Connection error, RemoteProtocolError, and then exhausted fallback attempts.</description>
    </item>
  </channel>
</rss>
