Multi-WAN policy route misconfiguration decision tree — WeChat sends images but Feishu cannot

Q: tracert shows Feishu media IP taking the wrong egress — how do I confirm it is policy routing?

Log into the router and check show ip route plus the policy-based routing (PBR) table; find the rule matching Feishu's media IP range and verify its next-hop / WAN interface. Then temporarily move that traffic to the backup WAN (or delete the bad rule and use the default route); if Feishu recovers, it is confirmed. Also compare the "source interface / source address" condition — many policies are built per internal VLAN, and the miss often happens when a new VLAN was never added.

I have seen a confusing office-network failure: staff say "Feishu cannot send images or files, but text chat is fine, and WeChat images work with no problem". The first reflex drifts toward "Feishu server is down" or "Feishu client bug", and some even go check DNS — yet the Feishu web client logs in and texts send; only rich media stalls.

The signature of this fault is "single app, single traffic type" — it distinguishes "everything is down" from "only one app's media stream was misrouted". The decision tree below handles the "some SaaS media won't flow under multi-WAN" class.

60-second check — is it an egress routing problem?

Self-test with one sentence:

WeChat images fine, Feishu images/files fail but text works; or app A fine, app B media only stalls → strongly suspect multi-WAN policy routing sent the media stream out the wrong egress.

If every app and every traffic type stalls, that is one WAN fully down or a gateway problem — outside this page.

Troubleshooting decision tree

User reports: Feishu logs in and texts, but images/files won't send (WeChat works)
  │
  ├─ Confirm the scope
  │    ├─ Only Feishu media stalls? Other SaaS fine? → single-app media problem (check PBR)
  │    └─ Multiple SaaS media all stall?              → likely primary WAN congested/down (check WAN status)
  │
  ├─ Resolution layer (rule out DNS)
  │    ├─ nslookup Feishu media domain returns IP?
  │    │     → resolution fine, not DNS, go check egress
  │    └─ nslookup times out / wrong?                → go check DNS push (see internal DNS decision tree)
  │
  ├─ tracert -d <Feishu media server IP>
  │    ├─ First hop already took the "broken/congested WAN" gateway? → PBR misrouted this IP range ★most common
  │    └─ Took the correct WAN but still drops?       → that WAN link itself is bad (check link quality)
  │
  ├─ Log into router, check policy-based route (PBR) table
  │    ├─ Rule matching Feishu media range points to wrong next-hop? → fix rule to primary WAN
  │    ├─ No such rule, but source-VLAN default landed it on backup WAN? → add explicit rule
  │    └─ Rule exists but "source interface" missed the new VLAN? → include the new VLAN in policy
  │
  └─ Root-cause locating
       ├─ Fail over to backup/default egress and Feishu recovers? → confirmed misconfig, stopgap
       └─ Still fails?                                      → not routing, check that WAN link or Feishu side

The hinge of the whole tree is one line: decide first whether it is DNS/server or egress path selection, then choose whether to check the domain or the route table. That tracert step at the front is the pivot — it exposes directly which WAN the media IP actually took.

Three-step locating commands

Step 1 — confirm it is not DNS and grab the real media IP

nslookup <feishu-media-domain>     :: resolution fine means not DNS; note one returned media IP
ping <that media IP>               :: reachable means layer-3 is up; problem is "path choice" not "reachability"

Note: a SaaS media CDN domain is usually different from its login domain — query the "media/file" domain, not the login one.

Step 2 — see which egress the media actually took

tracert -d <feishu media IP>       :: the first-hop gateway address reveals which WAN it used

Compare the tracert first-hop gateway IP against each WAN interface's gateway on the router: if it landed on the WAN that "should never carry Feishu media", that is the PBR misconfiguration.

Step 3 — log into the router and check policy routing and the route table

show ip route                              :: which route / next-hop matches the destination range
show route-map / show policy-map           :: view PBR policy (syntax varies by vendor)
display policy-based-route                 :: common on Huawei-style gear

Key checks: does the rule matching Feishu media range point to the primary WAN interface; and does its "match condition" miss the affected internal VLAN/source range.

Emergency stopgap — temporarily fail back to the correct egress

This is not a script — the fix must be done on the router/firewall, there is no terminal equivalent, so below is the checklist of what to look at and change, not pretend-remote execution:

1. Confirm Feishu media IP ranges (from official docs or nslookup, at least /24 granularity)
2. In policy routing, explicitly set this range to the primary WAN interface + correct next-hop
3. Before saving, test in session: tracert to that IP should immediately take the primary WAN
4. After Feishu images recover, harden the rule into config and back it up

Honest note: fixing multi-WAN policy routing must be done on the router/firewall device; the endpoint side has no equivalent script. The above is a checklist for troubleshooting and changing config, not copy-run code; commands differ greatly by vendor (Cisco/Juniper/Huawei/Fortinet), always follow your device documentation.

Root cause — stop the misconfiguration from recurring

Failing one host back is only a stopgap. Every new SaaS on a multi-WAN network adds a set of media IP ranges to manage; close it off in three layers:

Layer	Action	Prevents
Routing	Map and draw the multi-WAN route master table; pin core SaaS (Feishu/DingTalk/Meeting) media ranges to the primary WAN	media stream misrouted to dead/congested egress
Process	Build a "New SaaS network policy assessment SOP": before launch, pull official IP ranges, write into PBR, name an owner	new app misses config; IP range change not synced
Monitoring	Probe core WAN link quality (latency/loss/jitter); auto-alert or fail over when primary degrades	primary WAN silently degrades unnoticed

One often-missed point: a SaaS media IP range shifts as the vendor schedules. DingTalk, Feishu and Tencent Meeting media CDNs all expand ranges dynamically; the SOP must state who tracks IP-range changes and how soon they sync to routing, or today's correct rule expires in three months.

Quick decision table (use it directly)

Symptom	First reflex (misjudged)	Real root cause	Where to look
WeChat images fine, Feishu images fail	Feishu server down / client bug	Feishu media IP range misrouted by PBR	tracert media IP + PBR table
Text works, images stall	DNS resolution error	asymmetric route / media egress dead	compare WAN gateways, check link quality
One VLAN all affected, others fine	Feishu throttling that dept	new VLAN missed in PBR	PBR source interface/address condition
Recovers on failover to backup	problem gone, ignore it	only stopgap, misconfig remains	harden primary-egress rule
nslookup media domain times out	Feishu media server down	actually wrong DNS push (see DNS tree)	endpoint ipconfig /all DNS

This table is the landing version of "what it is most easily misjudged as" — eight out of ten tickets of this class open as "Feishu is broken", and checking against this table skips most wasted effort.

FAQ

Q: Why does WeChat work but Feishu cannot send images?
A: WeChat and Feishu media ride different vendors' CDN/object storage, so they use different IP ranges. Multi-WAN routing picks the egress by destination IP; if policy routing sends Feishu's media range out the broken or congested WAN, Feishu images/files stall while WeChat media (on the healthy WAN) works. Text chat rides a long-lived signaling connection on a different path, so text keeps working.

Q: tracert shows Feishu media IP taking the wrong egress — how do I confirm it is policy routing?
A: Log into the router and check show ip route plus the policy-based routing (PBR) table; find the rule matching Feishu's media IP range and verify its next-hop / WAN interface. Then temporarily move that traffic to the backup WAN (or delete the bad rule and use the default route); if Feishu recovers, it is confirmed. Also compare the "source interface / source address" condition — many policies are built per internal VLAN, and the miss often happens when a new VLAN was never added.

Q: It recovered after failing over to the backup egress — can I leave it?
A: Failing over is only a stopgap. If the backup WAN also fails later, the fault returns; and asymmetric routing (forward on A, return on B) can also break some CDNs' origin checks. Go back to the PBR table, pin Feishu (and peer SaaS) media ranges to the correct primary WAN, and write it into the assessment SOP so new apps stop hitting the same hole.

Q: Where do teams most often trip when adding a new SaaS (DingTalk / Tencent Meeting)?
A: Most often they whitelist the login domain but forget the media IP ranges. A SaaS login domain and its media CDN domain are usually different, and media IP ranges shift as the vendor schedules. The SOP must require pulling the vendor's published media/call-server IP ranges, pinning them to the primary WAN in policy routing, and naming an owner for "IP range changed → route updated".

Q: How do I tell this apart from a DNS resolution issue?
A: A DNS issue fails the whole domain (including login) and nslookup of the media domain returns wrong/timeout results. This class shows "domain resolves, login works, only media stalls at the egress". One-line test: nslookup of the Feishu media domain is fine, but tracert to its IP takes the wrong WAN — that is policy routing, not DNS.