English
- Introduction
- Tech Stack
- Installation and Configuration
- Library Usage
- Design Philosophy
- File Structure
- A Little History
Introduction
proxy_http is a lightweight, high-performance, asynchronous HTTP proxy server built with Rust. Its primary function is to route outgoing traffic through a dynamic pool of upstream proxy servers, fetched from external subscription links. It is designed for scenarios that require robust IP rotation, enhanced user anonymity, or bypassing network restrictions. The server also includes basic authentication to ensure controlled access. It can be used as a library in your Rust projects or run as a standalone binary.
Tech Stack
This project leverages modern, efficient, and battle-tested Rust libraries to achieve high performance and reliability:
- Tokio: An asynchronous runtime for writing fast and reliable network applications.
- Hyper: A fast, safe, and correct HTTP implementation for Rust, serving as the foundation of the proxy server.
- proxy-fetch: A utility to fetch and manage lists of upstream proxy providers from subscription URLs.
- Reqwest: An ergonomic, higher-level HTTP client used for integration testing.
- ThisError: A library for creating descriptive, structured error types, simplifying error handling.
Installation and Configuration
You can run this project as a standalone application.
Installation
Install the binary using cargo:
Configuration
The application is configured via environment variables.
PROXY_SUBSCRITION_URL: Required. A semicolon-separated list of subscription URLs for fetching upstream proxy servers.PROXY_USER: Required. The username for clients to authenticate with this proxy server.PROXY_PASSWORD: Required. The password for clients to authenticate.PORT: Optional. The port for the proxy server to listen on. Defaults to15080.
Running
Once installed and configured, simply run the binary:
The server will start and listen on the configured port (e.g., 0.0.0.0:15080).
Library Usage
The following examples, adapted from the integration tests in tests/main.rs, demonstrate how to use proxy_http as a library.
Example 1: Standard HTTP Proxy Request
This test initializes the server, sends a request with incorrect credentials to verify authentication, and then sends a successful request.
async
Example 2: HTTP Tunnel (CONNECT)
This test establishes an HTTP tunnel for a CONNECT request, which is typically used for HTTPS traffic.
async
Design Philosophy
The design of proxy_http adheres to several core principles: Asynchronous, Modular, and Minimalist. The request handling process clearly illustrates this design.
Request Flow
The server handles two main types of requests: standard HTTP proxy requests and CONNECT tunnel requests.
-
Connection Acceptance (
run.rs): Therunfunction binds aTcpListenerto the specified address. It enters a loop, accepting incoming TCP connections. For each connection, it spawns a new asynchronous Tokio task to handle it concurrently. -
Request Handling (
handle.rs): Inside the task,hyperserves the connection. For each incoming HTTP request, the centralhandlefunction is called. -
Authentication (
is_authorized.rs): Thehandlefunction first callsis_authorizedto check theProxy-Authorizationheader. If authentication fails, it immediately returns a407 Proxy Authentication Requiredresponse. -
Request Routing (
handle.rs):- For
CONNECTrequests: Thehandlefunction identifies theCONNECTmethod. It initiates a protocol upgrade on the connection viahyper::upgrade::on. The resulting upgraded TCP stream (a tunnel) is passed to theupgrade::upgradefunction. - For standard HTTP requests: The
handlefunction passes the request directly to theproxy::proxyfunction.
- For
-
Forwarding Logic:
- Inside a Tunnel (
upgrade.rs): Theupgradefunction serves the established tunnel. It reads subsequent requests from the client within the tunnel and uses theproxy::proxyfunction to forward them to their destination through an upstream proxy. - Standard Forwarding (
proxy.rs): Theproxyfunction is the core forwarding engine. It takes the request, cleans up proxy-specific headers, and uses theproxy_fetchinstance to execute the request against a chosen upstream proxy. It then reconstructs the response and sends it back to the client.
- Inside a Tunnel (
This modular flow ensures a clear separation of concerns: run manages connections, handle authenticates and routes, upgrade manages tunnels, and proxy forwards the traffic.
File Structure
The project is organized to promote clarity and separation of concerns:
Cargo.toml: Defines project metadata, dependencies, and build settings.src/main.rs: The main entry point for the executable, responsible for initializing and running the proxy server.src/lib.rs: The library's root, which declares and exposes the server's core modules.src/error.rs: Defines custom, structured error types for the application usingthiserror.src/handle.rs: The main request handler. It performs authentication and routes requests to either the standard proxy logic (proxy.rs) or theCONNECTtunnel logic (upgrade.rs).src/is_authorized.rs: Implements theProxy-Authorizationheader check.src/proxy.rs: Contains the core request forwarding logic. It prepares and sends outgoing requests to an upstream proxy provider, and is used by both the standard proxy and theCONNECTtunnel handlers.src/run.rs: Contains the mainrunfunction that binds the server to a socket and spawns tasks for each incoming connection.src/upgrade.rs: HandlesCONNECTrequests by setting up a TCP tunnel to the destination and forwarding traffic.tests/main.rs: Contains integration tests that verify the end-to-end functionality of the proxy server.
A Little History
The concept of proxy servers is nearly as old as the web itself. The first proxies were developed at CERN in the early 1990s, around the same time Tim Berners-Lee was creating the World Wide Web. Initially, they were used as "gateways" to handle different protocols, but their role quickly evolved into caching, which was crucial for reducing traffic on the slow and expensive international networks of the time. This simple yet powerful idea of an intermediary has since become a fundamental building block of modern network architecture, enabling everything from security and content filtering to the very distributed systems this project relies on.
中文
项目简介
proxy_http 是一个使用 Rust 构建的轻量级、高性能、异步 HTTP 代理服务器。其核心功能是通过从外部订阅链接获取的动态上游代理服务器池来路由出站流量。它专为需要 IP 轮换、增强用户匿名性或绕过网络限制的场景而设计。服务器还包含基本身份验证功能,以确保访问受控。它既可以作为库在您的 Rust 项目中使用,也可以作为独立的可执行文件运行。
技术栈
本项目利用了现代化、高效且经过实战检验的 Rust 库,以实现卓越的性能和可靠性:
- Tokio: 一个用于编写快速、可靠网络应用的异步运行时。
- Hyper: 一个快速、安全且正确的 Rust HTTP 实现,是本代理服务器的基石。
- proxy-fetch: 一个用于从订阅 URL 获取和管理上游代理提供者列表的工具库。
- Reqwest: 一个符合人体工程学的高级 HTTP 客户端,用于集成测试。
- ThisError: 一个用于创建描述性、结构化错误类型的库,简化了错误处理。
安装与配置
您可以将此项目作为独立的应用程序运行。
安装
使用 cargo 安装二进制文件:
配置
该应用程序通过环境变量进行配置。
PROXY_SUBSCRITION_URL: 必需。用于获取上游代理服务器的订阅 URL,多个 URL 之间用分号分隔。PROXY_USER: 必需。供客户端连接此代理服务器时进行身份验证的用户名。PROXY_PASSWORD: 必需。供客户端进行身份验证的密码。PORT: 可选。代理服务器监听的端口。默认为15080。
运行
安装和配置完成后,直接运行二进制文件即可:
服务器将启动并监听配置的端口(例如 0.0.0.0:15080)。
作为库使用
以下示例改编自 tests/main.rs 中的集成测试,演示了如何将 proxy_http 作为库来使用。
示例一:标准 HTTP 代理请求
此测试初始化服务器,首先用错误的凭据发送请求以验证身份验证功能,然后发送一个成功的请求。
async
示例二:HTTP 隧道 (CONNECT)
此测试为 CONNECT 请求建立 HTTP 隧道,该请求通常用于 HTTPS 流量。
async
设计思路
proxy_http 的设计遵循几个核心原则:异步、模块化和极简主义。请求处理流程清晰地展示了这一设计思想。
请求流程
服务器主要处理两种类型的请求:标准 HTTP 代理请求和 CONNECT 隧道请求。
-
连接接收 (
run.rs):run函数将一个TcpListener绑定到指定地址。它进入一个循环,接收传入的 TCP 连接。对于每个连接,它会生成一个新的异步 Tokio 任务来并发处理。 -
请求处理 (
handle.rs): 在任务内部,hyper负责处理该连接。对于每个传入的 HTTP 请求,都会调用中央的handle函数。 -
身份验证 (
is_authorized.rs):handle函数首先调用is_authorized来检查Proxy-Authorization头。如果身份验证失败,它会立即返回407 Proxy Authentication Required响应。 -
请求路由 (
handle.rs):- 对于
CONNECT请求:handle函数识别CONNECT方法。它通过hyper::upgrade::on在连接上启动协议升级。由此产生的升级后的 TCP 流(一个隧道)被传递给upgrade::upgrade函数。 - 对于标准 HTTP 请求:
handle函数将请求直接传递给proxy::proxy函数。
- 对于
-
转发逻辑:
- 在隧道内部 (
upgrade.rs):upgrade函数负责处理已建立的隧道。它从客户端读取隧道内的后续请求,并使用proxy::proxy函数通过上游代理将它们转发到目的地。 - 标准转发 (
proxy.rs):proxy函数是核心的转发引擎。它接收请求,清理代理特定的头部,并使用proxy_fetch实例通过选定的上游代理执行请求。然后,它重新构建响应并将其发送回客户端。
- 在隧道内部 (
这种模块化的流程确保了清晰的关注点分离:run 管理连接,handle 进行身份验证和路由,upgrade 管理隧道,而 proxy 负责转发流量。
文件结构
项目结构清晰,旨在促进关注点分离:
Cargo.toml: 定义项目元数据、依赖项和构建配置。src/main.rs: 可执行文件的主入口点,负责初始化和运行代理服务器。src/lib.rs: 库的根模块,声明并导出服务器的核心模块。src/error.rs: 使用thiserror为应用程序定义自定义的结构化错误类型。src/handle.rs: 主请求处理器。它执行身份验证,并将请求路由到标准代理逻辑(proxy.rs)或CONNECT隧道逻辑(upgrade.rs)。src/is_authorized.rs: 实现Proxy-Authorization头的检查逻辑。src/proxy.rs: 包含核心的请求转发逻辑。它负责准备请求并将其发送到上游代理,供标准代理和CONNECT隧道处理器共同使用。src/run.rs: 包含主run函数,负责将服务器绑定到套接字并为每个传入连接创建任务。src/upgrade.rs: 处理CONNECT请求,通过建立到目标的 TCP 隧道来转发流量。tests/main.rs: 包含集成测试,用于验证代理服务器的端到端功能。
相关历史
代理服务器的概念几乎与万维网本身一样古老。最早的代理是 1990 年代初在欧洲核子研究中心(CERN)开发的,大约在蒂姆·伯纳斯-李(Tim Berners-Lee)创建万维网的同一时期。最初,它们被用作处理不同协议的“网关”,但其角色很快演变为缓存,这对于在当时缓慢而昂贵的国际网络上减少流量至关重要。这个简单而强大的中介理念,后来成为现代网络架构的基本构建块,支撑着从安全、内容过滤到本项目所依赖的分布式系统等各种技术。
About
This project is an open-source component of i18n.site ⋅ Internationalization Solution.
-
i18 : MarkDown Command Line Translation Tool
The translation perfectly maintains the Markdown format.
It recognizes file changes and only translates the modified files.
The translated Markdown content is editable; if you modify the original text and translate it again, manually edited translations will not be overwritten (as long as the original text has not been changed).
-
i18n.site : MarkDown Multi-language Static Site Generator
Optimized for a better reading experience
关于
本项目为 i18n.site ⋅ 国际化解决方案 的开源组件。
-
翻译能够完美保持 Markdown 的格式。能识别文件的修改,仅翻译有变动的文件。
Markdown 翻译内容可编辑;如果你修改原文并再次机器翻译,手动修改过的翻译不会被覆盖 ( 如果这段原文没有被修改 )。
-
i18n.site : MarkDown 多语言静态站点生成器 为阅读体验而优化。