pass Panel Introduction
The pass panel is a private-protocol tunnel networking tool, consisting of a panel management side and a server side.
TIP
Contact @soga_boy_bot on Telegram to purchase
Introduction
- Private tunnel protocol: An in-house tunnel protocol, not an implementation of any public protocol. Supports connection multiplexing to reduce handshake overhead and latency.
- The panel is the config: Changes made in the panel are automatically synced to all nodes.
- Easy installation: One-click script install. No need for BT Panel, MySQL, PHP, or Docker. Backing up means copying a single file, and migrating is just a matter of switching to another machine.
- Relay that never goes down: Four load balancing strategies + active health check + failover + backup nodes / backup exits / backup hubs. If the next hop goes down, traffic is switched away automatically, and switched back once it recovers.
- Built-in AI assistant: Once an LLM API is configured, AI can operate the panel and troubleshoot forwarding issues for you. An MCP interface is also supported, letting other more powerful agents (such as Codex and Claude Code) troubleshoot problems.
- Proxy Protocol: Can receive and send Proxy Protocol to pass the real client IP to the exit.
- Two server editions: Golang edition and Rust edition (higher performance, lower memory usage).
- Kernel forwarding: Ports are forwarded directly by the system kernel, with high performance and low resource usage. Ideal when you only need port forwarding.
Common Use Cases
TIP
═ indicates an encrypted tunnel, → indicates a direct connection.
| Use case | Path |
|---|---|
| Plain port forwarding | User → Entry → Exit |
| Encrypted tunnel relay | User → Domestic entry ═〔Firewall〕═ Overseas relay → Exit; multiple relays can be chained |
| Hub forwarding | User → Entry ═〔Firewall〕═ Hub → Any exit; one hub serves all exits |
| SOCKS5 dedicated-line relay | Set the hub's transport type to SOCKS5: User → Entry →〔Dedicated line〕→ Hub → Exit |
| Kernel forwarding | User → Entry → Relay (optional) → Exit; unencrypted, high performance |
| Port range forwarding | Entry 10000-10100 → Exit 20000-20100, mapped one to one |
| Passing the user's real IP | Enable sending Proxy Protocol on the forwarding rule or hub, and enable receiving on the exit |
| SNI routing | A single entry port, routed to different exits by TLS domain; wildcards supported |
| Load balancing and failover | Traffic is distributed automatically across multiple exits, relays, or hubs, and switched away from any that go down |
Supported Protocols
TIP
The transport layer supports TCP + UDP and IPv4 + IPv6, as well as MPTCP and custom TLS client fingerprints.
| Protocol | Description | Usable for |
|---|---|---|
| Direct | Forwarded as-is, unencrypted | Inbound protocol, relay protocol |
| TLS | Standard TLS encryption | Inbound protocol, relay protocol |
| SNI routing | Routes to different exits by TLS domain | Inbound protocol |
| TCP tunnel | Encrypted with the private tunnel protocol | Inbound protocol, relay protocol, hub |
| TLS tunnel | Tunnel + TLS dual-layer encryption | Inbound protocol, relay protocol, hub |
| WebSocket tunnel | Tunnel protocol over WebSocket | Inbound protocol, relay protocol, hub |
| WebSocket + TLS tunnel | WebSocket tunnel + TLS dual-layer encryption | Inbound protocol, relay protocol, hub |
| REALITY tunnel | Disguised as visits to a real website; no certificate of your own required | Inbound protocol, relay protocol, hub |
| SOCKS5 | Standard socks5 proxy | Hub |
The inbound protocol is the protocol users use to connect to the entry; the relay protocol is the protocol used between the entry and the relay; a hub is a relay server shared by multiple forwarding rules, with a single hub port serving all exits.
Load Balancing
Takes effect when a segment has multiple targets: multiple exits, multiple nodes selected for a relay or hub, or multiple hubs.
| Strategy | Description | Best for |
|---|---|---|
| Round robin | Each connection uses the next target in turn | Exit servers with similar specs, spreading load evenly |
| ip_hash | The same source IP is always assigned to the same target | Cases that need a stable egress IP (login sessions, risk-control-sensitive services) |
| fallback | Always prefers the first target, moves to the next if it goes down, and switches back once it recovers | Primary/backup setups: primary line first, backup line as a safety net |
| Least connections | Always picks the target with the fewest current connections | Connections with widely varying durations, balancing by actual load |
Active Health Check
Periodically opens a TCP connection to each target to determine whether it is available:
- x consecutive failures → marked unavailable, and no more traffic is assigned to it
- y consecutive successes → marked recovered, and traffic is assigned to it again
- Check interval of n seconds;
n / x / yall have defaults and can be adjusted
Failover (ip_hash only)
If the target a user is assigned to goes down, the user is automatically reassigned to another available target and pinned there, then switched back once the original target recovers.
Backup
An exit can be set as "Backup only", a relay can have "Backup nodes", and hub forwarding can have "Backup hubs". Backups are only used when all primary targets are unavailable; load balancing also works across backups.
Other Features
| Feature | Description |
|---|---|
| Node status display | CPU, memory, swap, disk, connections, real-time speed, system traffic |
| Node offline alerts | Telegram Bot notifications when a node goes online / offline |
| Certificate management | Automatic issuance and renewal |
| Automatic domain resolution | When a forwarding target is a domain, its DNS changes are followed automatically |
| Online IP records | Records online IPs, connections, traffic, and more for each forwarding rule |
| Automatic config sync | Config changes in the panel are automatically synced to all nodes |
| Connectivity probing | The forwarding list shows the connectivity and latency of each segment in real time |