reverse-proxy-for-agents

Route and secure AI agent HTTP, WebSocket, and LLM-router traffic with reverse proxy configurations.

2|Updated Feb 11, 2026
One-click install
npx skills add https://github.com/curiositech/port-daddy --skill reverse-proxy-for-agents
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: reverse-proxy-for-agents
Source: https://github.com/curiositech/port-daddy/tree/main/skills/reverse-proxy-for-agents
Command: npx skills add https://github.com/curiositech/port-daddy --skill reverse-proxy-for-agents

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill removes the complexity of routing, protecting, and scaling network traffic for AI agent fleets by providing clear patterns for reverse proxies, TLS termination, load balancing, WebSocket streaming, and agent identity propagation so agents can communicate reliably without port conflicts or budget exhaustion.

Core Features & Use Cases

  • Protocol-aware routing: Path- and content-based routing for HTTP, WebSocket, and LLM-router traffic with support for Nginx, Caddy, Traefik, and Cloudflare.
  • Resilience & state handling: Health checks, sticky sessions, ip_hash, and shared-state alternatives to prevent context loss for stateful agents.
  • Streaming & performance: Streaming-friendly proxying (disable buffering, long timeouts), keepalive and worker tuning for high-throughput scenarios.
  • Safety & cost control: Rate limiting, per-key/IP quotas, and classifier recommendations to avoid heavy on-proxy LLMs and runaway billing.
  • Integration patterns: Agent gateway pattern, service mesh considerations (Envoy/Istio), and MCP server proxying for multi-agent architectures.
  • Use Case: Deploy a Caddy or Nginx gateway that routes code, research, and data agents with health checks, WebSocket upgrades, sticky sessions for stateful workloads, and per-client rate limits to protect budgets.

Quick Start

Use the reverse-proxy-for-agents skill to generate a production-ready Nginx, Caddy, or Traefik configuration that routes agent traffic with health checks, WebSocket support, sticky sessions, and rate limiting.

Frequently Asked Questions about reverse-proxy-for-agents

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I configure a reverse proxy for AI agents with WebSocket and HTTP routing?

Configuring a reverse proxy for AI agents involves routing HTTP and WebSocket traffic using Nginx, Caddy, or Traefik. You need protocol-aware path routing, TLS termination, and health checks to ensure reliable agent communication without port conflicts.

What is the best way to load balance stateful AI agents without losing context?

Load balancing stateful AI agents requires sticky sessions or ip_hash to maintain context. Nginx and Traefik support these patterns, routing WebSocket connections to specific agents and preventing context loss during high-throughput streaming scenarios.

How do I set up TLS termination and rate limiting for an LLM router gateway?

TLS termination and rate limiting for an LLM router gateway are set up by applying per-key or per-IP quotas at the proxy layer. This protects budgets and avoids runaway billing by limiting requests before they reach specialist agents.

Does this reverse proxy configuration support streaming responses and long-lived WebSocket connections?

Yes, streaming-friendly proxying supports long-lived WebSocket connections by disabling buffering and extending timeouts. This configuration applies to Nginx, Caddy, and Traefik deployments handling high-throughput agent traffic.

Can I use Traefik or Caddy instead of Nginx for routing multi-agent network traffic?

Yes, you can use Traefik or Caddy instead of Nginx for routing multi-agent traffic. The configuration patterns support all three proxies for protocol-aware routing, health checks, and sticky sessions across self-hosted and cloud deployments.

Why does my AI agent lose context when behind a load balancer?

AI agents lose context behind a load balancer when traffic is distributed without sticky sessions. Without ip_hash or shared-state alternatives, subsequent requests route to different agents, breaking stateful continuity for WebSocket and HTTP connections.