WeChat Relay — Fixed Egress IP for Official Account APIs
Fill the WeChat IP allowlist once: requests relay through a fixed egress IP, so moving servers or data centres never sends you back to the console.
In short
WeChat Relay is a forwarding service that gives WeChat Official Account API calls a fixed egress IP, permanently resolving errcode 40164 (invalid ip, not in whitelist). Swap api.weixin.qq.com for the relay domain, add an Authorization: Bearer header, and requests reach WeChat through one stable IP — that single address is all the platform allowlist ever needs, so changing servers, data centres or dial-up home broadband never means going back into the console. Paths, parameters and responses are identical to the official API: no SDK changes, no business-logic changes. ¥19.9 per year, with no cap on official accounts or call volume.
What the agent takes off people's plates
Core capabilities
A fixed egress IP — fill the allowlist once
The relay egress IP appears on the success page right after activation and stays fixed. Paste it once into Settings & Development → Basic Configuration → IP allowlist on the WeChat platform. From then on you can scale out, migrate data centres or even switch cloud vendors without ever touching the console again.
1 IP · filled once
Exactly two lines change
Replace https://api.weixin.qq.com with https://wechat-publish.ygg.com.cn and add one Authorization: Bearer <key> header. Paths, query parameters and response bodies match the official API exactly — no SDK swap, no business-logic rewrite, no change to how you already cache access_token.
2 edits · about 2 minutes
Works from home broadband and localhost
Running a publishing script from your own machine used to mean buying a cloud server purely to own a static IP, because every dial-up reconnection changed it. With the relay the egress IP comes from our side, so laptops, office networks and dynamic public IPs can all call the Official Account APIs directly.
Forwarded verbatim — nothing persisted, secrets redacted
Request bodies are forwarded verbatim over HTTPS end to end, with no content parsing and no persistence. Logs retain only timestamp, API path and status code; secret parameters such as AppSecret and access_token are automatically redacted. This is the question any relay of this kind deserves to be asked, so it is stated in the open.
One subscription, unlimited official accounts
Put the same egress IP into each account's allowlist — one subscription covers as many official accounts as you run, with no cap on call volume. Agencies, multi-brand matrices and a single developer maintaining several accounts all pay once.
Unlimited accounts · unlimited calls
Scan to activate, no approval queue
Log in with a phone number and SMS code; the moment WeChat Pay or Alipay clears, the relay key and egress IP appear. It is entirely self-serve with no manual review. When a subscription lapses the relay stops forwarding immediately, and renewing keeps the same IP and key, so the allowlist never has to be touched again.
Side by side
Using the relay vs renting a static-IP cloud server vs re-editing the allowlist every time
| Dimension | WeChat Relay (¥19.9/year) | Self-rented static-IP cloud server | Re-edit the allowlist on every change |
|---|---|---|---|
| Setup cost | Swap the domain, add one header — about two minutes | Build the forwarder yourself, configure HTTPS and certificate renewal | Nothing to set up, but the cost moves to every future change |
| When the server IP changes | Invisible — the egress IP is decoupled from your servers | Invisible, as long as that forwarding box itself never moves | Every call returns 40164 until someone logs in, edits and waits for propagation |
| Home broadband or localhost | Works directly; a dynamic public IP is irrelevant | Route requests through that server, lengthening the local debug loop | Effectively impossible — one reconnection changes the IP |
| Multiple official accounts | One subscription, any number of accounts, same IP in each allowlist | One box can serve many accounts, but the server bill is a standing cost | Edit each account separately — pain scales with account count |
| Ongoing cost | ¥19.9 per year with no call cap | Annual instance fee plus ops time and certificate upkeep | No cash cost, but every change buys you an outage to debug |
| Who handles your credentials | Passes through the relay (verbatim, not persisted, secrets redacted) | Only your own machine | Direct to WeChat, no third party involved |
Quantified before / after
Measured impact
How the agent and human supervision collaborate
System architecture (conceptual)
source
Your server or local script (IP changes)
agent
Relay service (Bearer auth · fixed egress IP)
human
WeChat platform allowlist (this one IP only)
output
WeChat Official Account API api.weixin.qq.com
Flow
- Your server or local script (IP changes)→Relay service (Bearer auth · fixed egress IP)New domain + Bearer key
- WeChat platform allowlist (this one IP only)→Relay service (Bearer auth · fixed egress IP)Register the egress IP once
- Relay service (Bearer auth · fixed egress IP)→WeChat Official Account API api.weixin.qq.comForward verbatim, paths unchanged
- WeChat Official Account API api.weixin.qq.com→Your server or local script (IP changes)Responses identical to official API
Verifiable facts
Numbers and sources
The service addresses WeChat Official Platform return code 40164 (invalid ip, not in whitelist), raised when the calling server's public IP is absent from the account's IP allowlist.
Integration takes exactly two edits: change the request host from api.weixin.qq.com to wechat-publish.ygg.com.cn and add an Authorization: Bearer <key> header. Paths, parameters and responses match the official API.
Pricing is ¥19.9 per year — one price, no call cap, and no limit on how many official accounts a single subscription covers. WeChat Pay and Alipay are both accepted.
Logs retain only timestamp, API path and status code; secret parameters such as AppSecret and access_token are automatically redacted; request bodies are forwarded verbatim over HTTPS end to end and are never written to disk.
The relay egress IP and key are shown on the success page immediately after activation and remain fixed long-term; when a subscription lapses the relay stops forwarding at once, and renewal leaves both the IP and the key unchanged.
Delivery and pricing
Pricing
Included
- · Relay forwarding through a fixed egress IP — that single address is all the platform allowlist needs
- · Unlimited calls, and one subscription covers any number of official accounts
- · End-to-end HTTPS, with paths, parameters and responses identical to the official API
- · Key and egress IP issued immediately after payment, with no manual review
Provided by the client
- · The official account's own verification, API permissions and rate quotas — all set by WeChat according to account type
- · Acquiring, caching and refreshing access_token — still your application's responsibility
- · Your own servers, domains and application code
Scan for the full solution document
Scan with WeChat to reach the solution lead and request the complete documentation and deployment checklist.
Where it fits
When this approach does not apply
- Traffic passes through YGG's relay servers. Even though requests are forwarded verbatim, never persisted, and secret parameters are redacted from logs, organisations under a hard compliance rule that credentials must not transit a third party — finance and government, typically — should still self-host a forwarder or connect directly.
- The relay adds a hop and is a single point of failure: if it is unavailable, your Official Account API calls fail. Availability-sensitive workloads should keep a direct-connection fallback in code, or health-check the relay before routing through it.
- It solves exactly one problem: the IP allowlist. WeChat's own API permission tiers, rate limits and access_token acquisition/expiry rules are unchanged, and the relay does not manage tokens for you — any endpoint you lack because of account type or missing verification stays unavailable through the relay too.
- When the subscription lapses the relay stops forwarding immediately and your integration breaks. Expiry is yours to watch: beyond the renewal reminder, add an alert on the relay path in your own monitoring.
Further reading