Home
Learning
WebSocket Proxying at the Edge

WebSocket Proxying at the Edge

By Gcore

August 28, 2026

2 min read

Network diagram illustrating secure data flow from client to edge and live processing.

FastEdge workers aren't limited to just responding to incoming requests — they can also make outbound network requests to external services. This opens up a world of possibilities: aggregating data from multiple APIs, proxying requests to upstream services, fetching remote content for caching, and more.

This post covers WebSocket Proxying at the Edge — a fundamental pattern for any edge application that needs to communicate with external services.

How It Works

Proxy and manage WebSocket connections at the edge — terminate WebSocket upgrades, authenticate before upgrading, and route to the right backend.

The FastEdge Rust SDK provides two approaches for making outbound requests:

Synchronous (fastedge::http_client) — simple, blocking API that works within the standard Request/Response handler model. Best for straightforward fetch-and-return scenarios.
Asynchronous (proxy-wasm dispatch) — uses the proxy-wasm ABI to pause request processing, make an HTTP call, and resume. Best for intercepting and augmenting client requests with external data.

Approach 1: Synchronous HTTP Client

The simplest approach — build a Request, send it, and get a Response back:

use fastedge::{ body::Body, http::{Request, Response, StatusCode, Error}, http_client, }; #[fastedge::http] fn main(req: Request<Body>) -> Result<Response<Body>, Error> { // Build an outbound request to an external API let upstream = Request::builder() .method("GET") .uri("https://httpbin.org/ip") .header("User-Agent", "fastedge-worker") .header("Accept", "application/json") .body(Body::empty()) .map_err(|_| Error::InvalidBody)?; // Send it from the edge let resp = http_client::send_request(upstream)?; // Forward the upstream response headers plus our own let status = resp.status(); let body = resp.into_body(); Response::builder() .status(status) .header("content-type", "application/json") .header("x-edge-cached", "false") .body(body) }

Approach 2: Async Proxy-Wasm Dispatch

For more advanced scenarios where you need to intercept a client request and augment it with external data:

use fastedge::proxywasm::*; use std::time::Duration; struct MyHttp { state: u32 } impl Context for MyHttp {} impl HttpContext for MyHttp { fn on_http_request_headers( &mut self, _: usize, _: bool ) -> Action { // Already got the data, continue the request if self.state == 1 { return Action::Continue; } // Pause the client request and fetch external data match self.dispatch_http_call( "api.example.com", // authority vec![ // headers (":scheme", "https"), (":authority", "api.example.com"), (":path", "/auth/check"), ("Authorization", "Bearer token123"), ], None, // no body vec![], // no trailers Duration::from_secs(5), // timeout ) { Ok(token) => { Action::Pause } Err(status) => { self.send_http_response( 502, vec![], b"Upstream unavailable" ); Action::Pause } } } fn on_http_call_response( &mut self, token_id: u32, num_headers: usize, body_size: usize, _: usize, ) { if num_headers > 0 { let body = self.get_http_call_response_body( 0, body_size ); // Store the response data and resume the client request self.state = 1; self.resume_http_request(); } else { // HTTP call failed, reset self.reset_http_request(); } } }

Common Use Cases

API aggregation — fetch data from multiple upstream APIs and combine into a single response.
Authentication — validate tokens against an external auth service before allowing access.
Content caching — fetch remote content on first request, cache at the edge for subsequent requests.
Proxying — act as a reverse proxy with additional processing such as header injection and body transformation.
Webhook forwarding — receive webhooks at the edge and fan them out to multiple downstream services.

Error Handling and Timeouts

Outbound HTTP calls are subject to network conditions. Always handle failures gracefully:

match http_client::send_request(upstream) { Ok(resp) => { handle_success(resp) } Err(e) => { logging::error!("Upstream call failed: {}", e); // Return a cached or fallback response instead of failing Response::builder() .status(StatusCode::OK) .header("content-type", "text/plain") .header("x-fallback", "true") .body(Body::from( "Service temporarily unavailable" )) } }

Caveat: Outbound requests from edge workers are subject to provider-configured timeouts (typically 5–30 seconds depending on your plan). Plan for failures with retries, circuit breakers, and fallback responses. Never assume an outbound call will succeed.

A glowing orange diagram illustrates data flow from client to edge, then to live processing, emphasizing security.

Running an MCP Server at the Edge

The Model Context Protocol (MCP) is an open protocol that standardizes how applications provide context and tools to LLMs. Think of it as a USB-C for AI — a universal interface that lets any LLM client communicate with any tool server witho

Diagram comparing Matchit and Regex for processing web requests, showing Matchit as faster and more efficient.

Routing with Matchit vs RegEx

Choosing the right routing strategy can make a significant difference in your FastEdge application's performance. This guide benchmarks three approaches on WASM.Approach 1: matchitmatchit is a Rust route-recognition library that uses a radi

Diagram showing a centralized KV data store connected to a web browser and global data centers.

Working with Edge KV Storage

This post covers Working with Edge KV Storage — a foundational pattern for stateful edge applications.How It WorksStore and retrieve key-value data at the edge. Perfect for config, feature flags, and session data distributed globally.Edge K

Diagram showing edge code securely accessing a secrets vault with authorized access control.

Using Environment Variables and Secrets

Security at the edge means threats are stopped before they reach your infrastructure. By implementing security logic in FastEdge workers, you can validate, filter, and block requests at the closest edge location to the user — providing the

Orange diagram shows data uploading, edge security, and S3 cloud storage.

Upload Files to S3 from the Edge

FastEdge provides distributed edge KV storage that lets you read and write data from any edge location worldwide. Unlike traditional centralized databases, edge KV stores data close to users — reads are served from the nearest PoP, making t

Data flow diagram from user, through secure Edge authentication, to an Origin server.

Token Exchange and Refresh at the Edge

CDN

DNS

Streaming

Fast Edge

Image Optimization

AI Inference

GPU Cloud

AI Cloud

Everywhere AI

Gclaw

Compute

Storage

Containers

Databases

Cloud Networking

Hosting

Colocation

WAF

DDoS Protection

Bot Management

API Security

How Microsoft scaled global content delivery

How ProSieben scaled GNTM's app TOPSHOT

How Higgsfield scaled AI video generation

How Fawkes Games stopped DDoS attacks

Gaming

Media & Streaming

Ecommerce & Retail

ERP Hosting

Fintech

Hosting Providers

Ecommerce Agencies

Online Education

iGaming

Dynamic Web Acceleration

Global Content Delivery

Multi-CDN Resilience

Live Streaming at Scale

Secure Cloud Computing

Cloud Migration

Bot Protection

Online Events

Digital Sovereignty

Using Gcore

Docs

API

Developer Tools

Insights

Blog

Case studies

Reports

Community

Events

Startup Program

Discord

Help

Help center

Support

Changelog

Service Status

Gcore status page

Meet Gcore

About us

Contact Us

Press

Press

Awards

Inside Gcore

Careers

Open positions

We're hiring

Help build the next chapter of the web

CDN

DNS

Streaming

Fast Edge

Image Optimization

AI Inference

GPU Cloud

AI Cloud