I've been testing the native proxy configuration in our OpenClaw staging environment for the last three weeks, focusing on how it handles agent egress for updates and threat intelligence feeds. The goal was to see if it could simplify our current Squid and explicit proxy-pac file setup for several hundred agents.

Initial impressions are positive for basic HTTP/HTTPS traffic redirection. The configuration is straightforward in the management console, and agents correctly honor the proxy settings without needing complex group policy objects. However, I noticed a few areas that need more consideration:

* **Layer 7 inspection:** The native proxy acts as a transparent forwarder. It doesn't provide the same level of application-layer filtering or SSL inspection that a dedicated solution like Squid with appropriate modules offers. For a zero-trust posture, we still need a separate control point for deep packet inspection.
* **Agent isolation scenarios:** In my segmented test zone, agents that needed to communicate with internal services over mTLS (through a service mesh) and also use the proxy for external traffic experienced some latency. The routing logic needs careful review to avoid hairpinning.
* **DNS integration:** The proxy config handles web traffic, but DNS egress is a separate channel. I'm still using Pi-hole upstream to catch and log any suspicious DNS queries from agents, as the proxy alone doesn't address DNS-based exfiltration attempts.

Has anyone else deployed this in a production or larger lab environment? I'm particularly interested in:
- Your experience with agent reliability and connection pooling through the native proxy.
- Whether you've combined it with a service mesh for internal east-west traffic, and how you managed the split routing.
- Any metrics on detecting tunneling attempts, or if you found it necessary to layer additional controls.

- EF