Deploying OpenClaw from my GitHub

Repository:https://github.com/halillea/openclaw (fork of openclaw/openclaw)

The application starts successfully and listens on port 6767, but all WebSocket connections to the Control UI fail with error code 1008 "pairing required" due to proxy trust configuration issues.

Technical Details:

1. Application Status: Gateway is running and healthy, listening on ws://0.0.0.0:6767

2. Error in Logs:

```

[ws] Proxy headers detected from untrusted address. Connection will not be treated as local. Configure gateway.trustedProxies to restore local client detection behind your proxy.

[ws] closed before connect conn=... remote=100.64.0.X fwd=81.243.93.183 code=1008 reason=pairing required

```

3. Root Cause: OpenClaw's gateway doesn't recognize Railway's proxy as trusted, so it treats all browser connections as remote/untrusted and enforces device pairing. The gateway needs to trust Railway's internal proxy network to allow local-like access.

4. Attempted Solutions (all failed):

- Environment variable: OPENCLAW_GATEWAY_TRUSTED_PROXIES=100.64.0.0/10

- Config file openclaw.json with: "gateway": {"trustedProxies": ["100.64.0.0/10"]}

- Various pairing policy overrides

- Multiple Telegram channel configuration attempts via both env vars and config file

5. Questions for Railway:

- What is the correct CIDR range for Railway's internal proxy network that should be added to trustedProxies?

- Are there specific Railway proxy headers X-Forwarded-For, X-Real-IP) that need special configuration?

- Does Railway's networking setup require additional configuration for WebSocket applications that validate proxy trust?

- Why aren't environment variables (like TELEGRAM_BOT_TOKEN, CHANNELS_TELEGRAM_ENABLED) being read by the containerized application despite being set in Railway's Variables?

Expected Behavior: WebSocket connections should be treated as trusted when coming through Railway's proxy, allowing the Control UI to connect without device pairing.