frp is a high-performance reverse proxy application that exposes local services behind NAT or firewalls to the internet. It implements a client-server architecture where the frpc client connects to the frps server, registers proxies (TCP, UDP, HTTP, HTTPS, STCP, XTCP, TCPMUX), and tunnels traffic through encrypted, compressed connections. The system supports multiple transport protocols (TCP, KCP, QUIC, WebSocket, WSS), authentication (token, OIDC), health checks, load balancing, bandwidth limiting, and a plugin system for both client and server extensions. It also includes NAT hole punching for direct peer-to-peer connections and an SSH tunnel gateway that allows SSH clients to create tunnels without frpc. The codebase is well-structured with clear separation of concerns: configuration loading and validation in pkg/config/, wire protocol and message handling in pkg/msg/ and pkg/proto/, network utilities in pkg/util/net/, and proxy implementations in server/proxy/ and client/proxy/. The project includes comprehensive end-to-end tests, a Vue.js web dashboard for both server and client management, Prometheus metrics, and a store API for dynamic proxy configuration at runtime. The architecture is modular, using factory patterns for proxy types, visitor patterns for P2P connections, and an aggregator pattern for merging configuration sources. Despite its complexity, the codebase is actively maintained with regular releases, extensive documentation, and a large community. It demonstrates strong engineering practices including interface-based design, dependency injection for testability, and careful concurrency management. The main technical debt is the coexistence of legacy INI configuration and v1 wire protocol alongside newer formats, but these are well-isolated and migration paths are provided.
Caddy is a production-grade, extensible web server platform written in Go. It automatically manages HTTPS certificates (via ACME/ZeroSSL) and provides a rich set of HTTP middleware including reverse proxy, file serving, authentication, compression, and headers manipulation. The architecture is modular: all features are registered as Caddy modules following a consistent lifecycle (Provision/Validate/Cleanup) and configured via a JSON config or the Caddyfile adapter. Key entry points are the CLI (caddy run, caddy start, etc.) and the admin API for runtime config changes. Primary data flows involve incoming HTTP requests being processed by a middleware chain of matchers and handlers, with TLS termination handled by the TLS app. External dependencies include certmagic for certificate management, zap for structured logging, Prometheus for metrics, and OpenTelemetry for tracing. The codebase is actively maintained with extensive test coverage and fuzz testing.
This repository is the source code for NGINX, a production-grade web server, reverse proxy, load balancer, API gateway, and mail proxy. The codebase is written entirely in C and is a definitive example of high-performance systems architecture. It employs a modular, event-driven, multi-process (master/worker) model. The core infrastructure is built around a set of highly optimized, self-contained data structures and utilities: a slab allocator for shared memory, a memory pool for request-scoped allocation, a red-black tree for timers and caches, a radix tree for IP routing, a hash table with wildcard support for server name matching, and an incremental JSON parser. The build system (auto/) is a sophisticated set of shell scripts that handle platform detection, dependency configuration, and module compilation. The code supports HTTP/1.x, HTTP/2, HTTP/3 (QUIC), TCP/UDP proxying (Stream module), and mail protocols (POP3, IMAP, SMTP). It is actively maintained, with a strong focus on performance, stability, and security. The code is exceptionally clean and well-structured for a project of its age and complexity, though it contains some platform-specific #ifdef sprawl and duplication between HTTP and Stream modules (e.g., upstream least_time, map).
YARP (Yet Another Reverse Proxy) is a high-performance, extensible reverse proxy toolkit for .NET, built on ASP.NET Core. It provides a library and samples for creating custom proxy servers with features including request forwarding, load balancing (random, round-robin, least-requests, power-of-two-choices), active and passive health checks, session affinity (cookie, hash, ARR, custom header), request/response transforms, and telemetry consumption. The architecture is middleware-based, with a pipeline that includes routing, load balancing, session affinity, health checks, and delegation (Http.sys). Configuration is driven by immutable records and supports dynamic reload via change tokens. YARP also includes a Kubernetes Ingress Controller module that watches Ingress, Service, Endpoint, and Secret resources to dynamically configure the proxy. The codebase demonstrates strong engineering practices: extensive unit and functional tests, pluggable policy interfaces, efficient stream copying with telemetry, and a transform builder pattern for declarative request/response modifications. It is actively maintained by Microsoft and used in production scenarios.
llama-swap is a production-grade reverse proxy and model router for local large language model (LLM) inference servers. It manages the lifecycle of upstream model processes (e.g., llama.cpp, vLLM), routes incoming OpenAI-compatible HTTP requests to the appropriate model based on configurable groups, matrix constraints, and peer definitions, and supports hot-swapping models without restarting the proxy. The system provides a rich web UI (Svelte 5) for monitoring activity, managing models, and running interactive playground tools including a documentation agent that answers questions via MCP tools. It also includes auxiliary utilities like a Wake-on-LAN proxy and a vLLM sleep mode wrapper. The architecture is a single Go binary with embedded static assets, internally modular with distinct packages for configuration (YAML with macros and deep merge), process management (state machine with health checks and TTL), routing (group and matrix DSL), hardware detection, performance monitoring, and activity storage (SQLite). External dependencies are limited to upstream model servers and optional remote peers. The codebase is actively maintained, well-tested, and demonstrates advanced engineering patterns such as a generic event pub/sub system, a ring buffer, composable HTTP middleware chains, a configurable matrix-based model selection DSL, and a poll-based directory watcher suitable for containerized environments.
docker-gen is a Go CLI tool that generates configuration files from Docker container metadata using Go templates. It connects to the Docker daemon, lists containers based on configurable filters (exposed ports, labels, etc.), and renders templates with container data (IPs, ports, environment variables, labels, networks). The generated output can be written to files or stdout, and docker-gen can notify services by running commands or sending signals to containers when the output changes. It supports watching Docker events for automatic regeneration with configurable debouncing. The architecture is a single binary with well-separated internal packages: config parsing, Docker client abstraction, container context extraction, template engine with custom functions (filtering, grouping, sorting, nginx-specific quoting/HSTS validation), and a generator that orchestrates event listening, signal handling, and file generation. The codebase is mature, extensively tested, and demonstrates high craftsmanship in its generic template helper functions (deepGet, where, groupBy, sortBy) which are reusable beyond this project. It is primarily used as part of the nginx-proxy ecosystem to auto-generate reverse proxy configurations, but can be adapted for any file generation from Docker metadata.
Traefik is a cloud-native reverse proxy and API gateway that dynamically configures itself from various service discovery backends (Docker, Kubernetes, Consul, etc.). It provides HTTP, TCP, and UDP routing, load balancing, TLS termination, ACME certificate management, a rich middleware chain (auth, rate limiting, compression, headers, etc.), observability (metrics, tracing, access logs), and a plugin system (Yaegi and Wasm). The project is written in Go with a React-based web UI. It supports Kubernetes CRDs (IngressRoute, Middleware, etc.) and the Gateway API. It has extensive integration tests and is actively maintained. The architecture is modular with clear provider interfaces, a configuration watcher that merges dynamic configs from multiple sources, and a hot-swappable handler for live updates.
Kong is a cloud-native, platform-agnostic API gateway built on OpenResty/Nginx. It provides traffic management, security, observability, and AI/LLM proxying capabilities through a plugin architecture. The system supports traditional, DB-less, and hybrid deployment modes, with an Admin API for configuration and Kong Manager for GUI-based management. Key features include load balancing, authentication, rate limiting, request/response transformation, and extensive observability integrations.
This repository implements a Caddy plugin that dynamically generates Caddy reverse proxy configurations from Docker container and Swarm service labels. It runs as a Caddy module, monitoring Docker events and polling Docker APIs to produce an in-memory Caddyfile, then loading it into Caddy with zero-downtime reloads. The system supports three operational modes: standalone (controller and server in one process), controller (generates config and pushes to remote Caddy servers via admin API), and server (receives config remotely). The core architecture comprises a Docker client abstraction, a Caddyfile generator that translates Docker labels into Caddyfile blocks, and a loader that manages event-driven updates. The codebase is well-structured with clear separation of concerns, extensive unit tests, and integration test suites using Docker Compose stacks. It demonstrates solid engineering practices with modular packages, concurrent-safe state management, and thorough error handling.
tsbridge is a production-grade reverse proxy that exposes multiple backend services on a Tailscale tailnet using isolated tsnet nodes per service. It supports static TOML configuration and dynamic Docker label discovery, with hot-reload, graceful shutdown, Prometheus metrics, and a composable middleware chain (access log, whois identity lookup, request ID, body size limits, header sanitization). The architecture is a single Go binary that manages per-service tsnet.Server instances, each with its own state directory and listener. External dependencies are Tailscale (tsnet), Docker (optional), and Prometheus. The codebase demonstrates strong engineering practices: interface-based abstractions (TSNetServer, config.Provider), typed error hierarchy, secret resolution with redaction, debounced event handling with exponential backoff, and comprehensive unit and integration tests. It is actively maintained with CI/CD, dependabot, and regular dependency updates.
Pomerium is an identity-aware access proxy enabling zero-trust network access to internal applications without a traditional VPN. It implements a microservices architecture with separate services for authentication, authorization, proxying (via Envoy), configuration synchronization (using Raft), and cluster management. The system integrates with identity providers (OIDC, SAML, LDAP), evaluates context-aware access policies, provides session management, and includes SSH bastion capabilities and Model Context Protocol (MCP) support for AI/LLM tool integration. A React-based administrative dashboard provides management capabilities.
zrok is a production-grade, self-hostable secure resource sharing platform built on OpenZiti overlay networking. It enables users to share web services, files, TCP/UDP tunnels, and VPN connections through firewalls and NAT without requiring inbound connectivity. The system supports both public and private sharing modes, OAuth authentication (GitHub, Google, OIDC), and includes a full REST API (v2), a CLI tool (`zrok2`), a React web console, a background agent daemon with gRPC remote control, and SDKs in Go, Python, and Node.js. Architecturally, zrok follows a controller-agent pattern. The controller is a Go REST server that manages accounts, environments, shares, accesses, frontends, namespaces, organizations, and bandwidth limits. It uses SQLite3 or PostgreSQL for persistence with versioned migrations, and integrates with InfluxDB for usage metrics and RabbitMQ (AMQP) for dynamic proxy mapping updates. The agent runs as a background process on the user's machine, managing child processes for each share/access and exposing a gRPC API for remote management. Frontend proxies (public, dynamic, socks, Caddy) handle incoming traffic with OAuth, basic auth, and interstitial pages. Key entry points include the CLI commands under `cmd/zrok2/` (e.g., `share`, `access`, `enable`, `admin`), the controller REST handlers in `controller/`, the agent gRPC service in `agent/agentGrpc/`, and the SDK packages in `sdk/golang/sdk`, `sdk/python/src/zrok2`, and `sdk/nodejs/sdk`. The system also includes a canary testing framework for continuous health validation and a comprehensive metrics/limits engine for bandwidth enforcement. External dependencies include OpenZiti (overlay network), InfluxDB (metrics), RabbitMQ (messaging), Caddy (optional web server), and various OAuth providers. The project is actively maintained with frequent commits, automated CI/CD, and multi-platform release pipelines (Linux, macOS, Windows, Docker).
Ocelot is a .NET library providing a highly configurable, middleware-based API Gateway for ASP.NET Core applications. It is not a standalone application but a framework that integrates into an ASP.NET Core host via `AddOcelot()` and `UseOcelot()`. Its architecture centers on a fixed-order middleware pipeline that processes incoming HTTP requests through stages including configuration loading, route matching, security, rate limiting, authentication, authorization, load balancing, URL rewriting, and proxying to downstream services. The pipeline is extensible through custom delegates and handlers, and supports advanced features like WebSocket proxying, response aggregation, and circuit breaking. The codebase demonstrates strong engineering practices with a clean separation of concerns across modules for Configuration, Routing, Load Balancing, Quality of Service, Rate Limiting, Caching, and WebSocket proxying. It features an extensive test suite with over a thousand unit and acceptance tests, many of which are linked to specific GitHub issues, indicating rigorous issue-driven development. The configuration system is particularly robust, supporting JSON file merging, environment-specific overrides, dynamic reloading, and fluent validation. While the core architecture is modern and well-maintained, targeting .NET 8 through 10, the codebase exhibits some technical drift. It relies on deprecated dependencies like `Microsoft.Extensions.DiagnosticAdapter` and `Newtonsoft.Json` alongside the newer `System.Text.Json`. There are known concurrency bottlenecks (e.g., a single static lock in rate limiting, blocking calls in the async configuration poller) and a reliance on reflection in unit tests that makes them brittle. Several properties are marked obsolete with planned removal in version 25.0. Despite this debt, Ocelot contains several genuinely reusable components that demonstrate non-obvious craftsmanship, such as a generic, thread-safe Circuit Breaker, a flexible Retry helper, and a clean DSL parser for claim transformations. It is an ideal choice for .NET teams requiring a robust, self-hosted, and extensible API gateway without the overhead of a commercial solution. Its primary value lies in its comprehensive feature set, extensibility, and the quality of its testing infrastructure.
https-localhost is a developer tool that runs an HTTPS server on localhost using locally-trusted SSL certificates. It downloads the mkcert binary appropriate for the host OS/architecture, executes it to install a local CA into system/browser trust stores, and generates per-host certificates. The resulting HTTPS server can either serve static files from a directory or act as a reverse proxy to an existing HTTP/HTTPS server, with optional HTTP-to-HTTPS redirection. It ships as both a global CLI (the `serve` binary) and a programmatic API (`createServer()`, `getCerts()`). Architecturally it is a small, well-separated set of ES modules built directly on Node's built-in http/https servers with no framework dependency. The router dispatches between a static file handler and a proxy handler; CORS headers are applied globally; environment/CLI configuration is validated through a zod schema where CLI flags take precedence over environment variables. External runtime dependencies are deliberately minimal: only `mrmime` for MIME lookup and `zod` for config validation, plus the downloaded mkcert binary. The static handler is the strongest piece: it implements path-traversal sanitization, ETag/Last-Modified conditional requests, byte-range responses (206/416), HEAD/OPTIONS support, directory index serving with query-preserving trailing-slash redirects, and custom 404.html lookup. The proxy handler strips hop-by-hop headers, injects X-Forwarded-* headers, tunnels WebSocket upgrades, and cleanly returns 502 when upstreams fail or die mid-response. Test coverage is comprehensive and genuinely exercises real sockets: unit tests for env parsing and certificate lifecycle, integration tests for static serving and proxying, CLI spawn tests, and edge-case tests for malformed percent-encoding, CORS preflight without upstream contact, and client hang prevention. CI runs a matrix across Ubuntu/macOS and Node 24/26 with strict type-aware linting, dead-code detection (knip), and formatting checks. Minor weaknesses: synchronous fs calls in the static handler (fine for a dev tool), a `process.exit()` call inside library code for unsupported platforms, minimal error handling in the mkcert download routine (only follows 302s, ignores non-2xx statuses), and no Windows CI coverage despite Windows-specific code paths.
sish is a production-grade, self-hosted SSH reverse tunneling server written in Go. It acts as a multiplexer that accepts SSH connections and forwards HTTP(S), WebSocket, TCP, and TLS (SNI) traffic to local services. Unlike ngrok or serveo, sish requires no custom client—users connect with standard SSH remote port forwarding. The server listens on SSH (default 2222), HTTP (80), and HTTPS (443) ports, and uses unix sockets for internal routing. It supports load balancing, TCP aliases, custom domains via DNS verification, on-demand Let's Encrypt certificates, and a real-time web console for inspecting forwarded requests. The architecture is monolithic but highly concurrent, leveraging goroutines and syncmap for state management. The codebase is well-structured with clear separation of concerns: SSH multiplexing (sshmuxer), HTTP handling (httpmuxer), and shared utilities (utils). It includes integration tests for authentication key requests and connection cleanup. The project is actively maintained with regular releases, CI/CD pipelines, and comprehensive documentation.
This repository is a reverse-proxy that translates ChatGPT's proprietary web API into OpenAI-compatible REST endpoints, enabling standard OpenAI SDK clients to generate images, edit images, have chat conversations, and search using ChatGPT's backend. It manages a pool of ChatGPT accounts, handles token refresh, proxy rotation, Cloudflare clearance (FlareSolverr, WARP), and provides a Next.js web dashboard for account management, image generation, settings, and backup. The backend is built with FastAPI and uses curl_cffi for HTTP impersonation, while the frontend is a modern React application with shadcn/ui components. The architecture is modular: protocol adapters in `services/protocol/` convert between OpenAI/Anthropic formats and ChatGPT's internal API, storage backends (JSON, SQLite, PostgreSQL, Git) abstract persistence, and services handle account lifecycle, image processing, and proxy configuration. The system is designed for self-hosted deployment via Docker Compose and supports advanced features like content filtering, chat completion caching, and editable file generation (PPT/PSD). Despite its strong engineering and active maintenance, the codebase is heavily dependent on reverse-engineering of ChatGPT's private API, making it fragile to upstream changes. The large single-file `OpenAIBackendAPI` class and limited test coverage are areas of concern, but the separation of concerns in storage, protocol, and service layers offers good reusability.
Sekiro is a multi-language, distributed RPC framework designed to expose capabilities from restricted or hard-to-reach environments. The server is a Java application built on Netty that listens on a configurable port (default 5612) and supports three transport protocols: a custom binary protocol (Sekiro native), HTTP, and WebSocket. It acts as a central hub: external consumers send invocation requests (via HTTP or the native protocol), and the server routes them to registered client handlers running in restricted environments (e.g., mobile apps, internal networks). The server maintains client groups with consistent hashing and queue-based load balancing, and handles heartbeats, timeouts, and connection lifecycle. It also includes a built-in proxy for serving documentation and static content. Architecturally, the server uses a protocol detection pipeline (ProtocolDetector) to identify the incoming protocol and install the appropriate handlers. For HTTP, it aggregates requests and delegates to ServiceHttp, which parses parameters and forwards invocations to the appropriate client group. For the native Sekiro protocol, it decodes packets and routes to RouterSekiro, which handles client registration and invoker connections. WebSocket clients are also supported for environments where raw TCP is unavailable. The system is stateless at the server level, with all client state managed in-memory via NettySekiroGroup instances. Key entry points are the Bootstrap.main() method, which starts the Netty server, and the various handler classes (ServiceHttp, RouterSekiro, ServiceSekiroClient, ServiceSekiroInvoker, ServiceWsClient). External dependencies include a custom Netty fork (sekiro-business-api), commons-lang3, SLF4J/Logback, and Lombok. The project uses Maven for building and includes a build script that produces a distributable zip. The codebase demonstrates solid engineering practices: clean separation of concerns, use of Netty's event loop model, a custom single-threaded event loop (Looper) for thread-safe group management, consistent hashing for client allocation, and a sampling-based event recording system for debugging. While the project is not a general-purpose RPC framework, it solves a specific niche (exposing capabilities from restricted contexts) effectively and with reasonable code quality.
Proxelar is a high-performance, scriptable local traffic workbench for HTTP, HTTPS, and WebSocket debugging. It functions as a man-in-the-middle (MITM) proxy that can capture, inspect, intercept, modify, replay, and export traffic across multiple protocols (HTTP/1.1, HTTP/2, HTTP/3, WebSocket, SOCKS5, DNS, UDP, and WireGuard). The system is built as a Rust workspace with four crates: `proxelar-cli` (binary with TUI, terminal, and web GUI interfaces), `proxyapi` (core proxy engine with TLS interception, Lua scripting, addon system, route rules, and session export/import), `proxelar-proto` (transport-neutral HTTP core with sans-I/O parsers for HTTP/1 and HTTP/2), and `proxyapi_models` (shared data types for headers, sessions, and captured exchanges). It supports forward and reverse proxy modes, declarative JSON routing rules, Lua addons with SHA-256 verification, and exports to HAR, curl, and raw formats. The architecture is modular with clean dependency direction, extensive integration tests, performance benchmarks, and property-based testing. It is a production-quality developer tool comparable to mitmproxy or Charles Proxy, with a focus on performance, correctness, and extensibility.
Nginx Proxy Manager is a full-stack web application that provides a graphical user interface and REST API for managing Nginx reverse proxy configurations, SSL/TLS certificates (via Let's Encrypt or custom uploads), TCP/UDP streams, access control lists, and user permissions. The system is designed to run as a Docker container and is primarily used by self-hosting enthusiasts and small-to-medium deployments to simplify the otherwise complex task of configuring Nginx and maintaining certificates. The architecture is a classic three-tier web application: a Node.js/Express backend (ES modules) with Objection.js/Knex ORM supporting SQLite, MySQL, and PostgreSQL; a React 18/19 frontend built with TypeScript, Vite, TanStack Query, and Tabler UI; and a set of s6-overlay managed services (backend, frontend, Nginx) inside a single Docker image. The backend generates Nginx configuration files from Liquid templates and reloads Nginx on any change. External dependencies include Nginx, Certbot (for Let's Encrypt), OpenSSL, and optionally a database server. Key entry points are `backend/index.js` (server startup, migration, setup, Express app) and `frontend/src/main.tsx` (React bootstrap). The primary data flow is: user creates or modifies a proxy host, redirection, stream, or certificate via the UI → API call → backend validates permissions and data → persists to database → regenerates relevant Nginx config files → tests configuration → reloads Nginx. The system also periodically checks for certificate expiration and renews via Certbot, and fetches IP ranges from Cloudflare/Cloudfront for access control. The codebase demonstrates solid engineering practices: a consistent internal service layer with access control and audit logging, a well-typed API client with automatic camelCase/decamelize conversion, a reusable table framework built on TanStack Table, and a comprehensive i18n system supporting 24+ locales. While some modules (e.g., certificate management) are large and could benefit from refactoring, the overall structure is clean and maintainable.
HTTPS-PORTAL is a Docker image that automates HTTPS setup using Nginx and Let's Encrypt. It provides a fully automated reverse proxy that obtains SSL certificates, configures Nginx, and handles renewal. The container runs multiple supervised processes via s6-overlay: Nginx, docker-gen (for automatic container discovery), cron (for certificate renewal), and a dynamic environment watcher. Configuration is driven by environment variables, primarily the `DOMAINS` variable which supports a rich syntax for specifying upstreams, redirects, basic auth, access restrictions, custom ports, and per-domain stages. The codebase is primarily Ruby scripts that parse domain descriptors, generate Nginx configuration from ERB templates, and orchestrate certificate signing via acme-tiny. The architecture is clean and modular, with clear separation between domain parsing, certificate management, and Nginx configuration generation. The repository includes comprehensive integration tests using Docker Compose and RSpec.