Summary

Allow Feishu/Lark channel traffic to use a channel-specific proxy policy so model-provider traffic can keep using env proxy while Feishu token/WebSocket traffic can go direct when needed.

Problem to solve

In a Windows setup where model-provider traffic needs HTTP_PROXY / HTTPS_PROXY, the Feishu channel can fail if Feishu/Lark API traffic inherits the same ambient proxy.

The practical mixed-proxy need is:

• LLM/provider requests: use env proxy
• Feishu/Lark token and WebSocket traffic: go direct, or follow an explicit channel policy

Today the workaround is awkward. Clearing proxy env globally can restore Feishu connectivity, but then provider requests may lose network access. A global proxy toggle is too coarse for this setup.

Proposed solution

A few possible solutions would work:

1. Document NO_PROXY guidance for Feishu/Lark endpoints in docs/channels/feishu.md.
2. Add a channel-level option, for example:

{
  "channels": {
    "feishu": {
      "proxyMode": "ambient" // or "direct"
    }
  }
}

3. Ensure Feishu HTTP and WebSocket paths use the same proxy policy and are covered by tests.

The main goal is to let provider traffic keep using env proxy while Feishu/Lark official endpoints can bypass that proxy when required.

Alternatives considered

Alternatives I tried/considered:

• Clearing all proxy env for the gateway process: helps Feishu, but can break model-provider traffic.
• Forcing Feishu SDK HTTP calls and WebSocket to direct locally: works for my machine, but a hard-coded proxy: false may break enterprise users who need Feishu/Lark through a corporate proxy.
• Asking users to manually tune env vars: possible, but this is easy to misconfigure and hard to diagnose from channel logs.

Impact

Affected users/systems/channels:

• Windows users running OpenClaw with Feishu/Lark channel in WebSocket mode
• Users whose model provider needs HTTP_PROXY / HTTPS_PROXY
• Mixed network environments where provider traffic and Feishu/Lark traffic need different routing

Severity: blocks workflow when it happens, because the Feishu bot receives no usable replies even though the gateway and channel config appear to be running.

Frequency: environment-dependent, but likely repeatable for users with incompatible local/corporate proxy routing.

Consequence: users spend time debugging Feishu credentials/events when the root cause is actually transport routing.

Evidence/examples

Observed in a local Windows setup:

• Feishu channel configured in WebSocket mode
• Gateway running
• Proxy env present: HTTP_PROXY, HTTPS_PROXY, ALL_PROXY
• Feishu token request failed against:

https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal

with:

400 The plain HTTP request was sent to HTTPS port

After forcing Feishu SDK HTTP calls and Feishu WebSocket connection to bypass the ambient proxy, Feishu started receiving and replying again. Keeping proxy env for the gateway process was still necessary for model-provider traffic.

I also checked current source: Feishu WebSocket already intentionally uses ambient env proxy, and shared NO_PROXY helpers already exist. So this seems better handled as an explicit/documented Feishu channel proxy policy rather than a blanket direct-connect patch.

Additional information

No credentials, tokens, app IDs, or app secrets are included here.

If maintainers agree on the preferred direction, I can help with either a docs-only PR for NO_PROXY guidance or a small implementation PR for a channel-level proxy policy.