登录

BackPack

AminMGMTAGPL-3.0活跃维护

用 Go 写的高性能隧道引擎，专门打通伊朗与境外服务器之间的连接，支持 TCP/UDP 和 IP 伪装，适合受限网络下的稳定传输。

BackPack is a high-performance tunnel engine for connecting Iran ⇄ abroad (kharej) servers

v1.8.5发布于 2026-09-30 11:11 UTC524star +3 / 7 天113fork同步于 2026-11-10 11:58 UTC
隧道引擎内网穿透IP伪装TCP/UDP反向隧道
对比 GitHub 官网backpackip-spoofip-spoofingip-spoofing-tunnelkcp

怎么上手

由 README 提炼，执行前请确认
原文 
bash <(curl -fsSL https://raw.githubusercontent.com/AminMGMT/BackPack/main/install.sh)
sudo backpack
硬件要求按 README 说明

README 未说明显存或 GPU 要求；安装包按 x86_64/amd64 与 aarch64/arm64 架构分发，TCP + PCK 与 xDi (ICMP) 传输需 Linux 且 root 权限。

下载：源码 zip·GitHub Releases（安装包）本站不镜像安装包

项目说明

由 README 自动翻译提炼
没人工点评？写下你的经验

用 Go 写的高性能隧道引擎，专门打通伊朗与境外服务器之间的不稳定链路

用 Go 写的高性能隧道引擎，专门打通伊朗与境外服务器之间的连接，支持 TCP/UDP 和 IP 伪装，适合受限网络下的稳定传输。

核心能力

  • 提供十二种反向隧道传输，含 TCP Mux、Stealth、PCK、KCP+FEC、QUIC、WS/WSS、ICMP
  • 支持完整三层直连隧道，用 GRE 封装加 Noise 加密承载整包 IP
  • 用 Setup Link 一行 backpack:// 链接把配置同步到境外端
  • 内置 Link Test 测量延迟、抖动与丢包并推荐传输方式
  • 带健康检查、自动故障切换、备份回滚与 Telegram 监控

容易踩的坑

伊朗端与境外端必须使用同一个 64 字符 token，不一致时隧道会表现为无响应；隧道端口与转发端口是两回事，伊朗端需放行隧道端口而境外端无需入站端口；转发端口默认只走 TCP，需要 UDP 的服务要单独在隧道设置里开启；WSS 传输需要自备证书，PCK 与 xDi 需 Linux + root。

内容由模型根据 README 生成，可能不完整或不准确，以官方文档为准。看原文 README

最近发版

5 个版本v1.8.5
全部 release
  1. v1.8.5Backpack v1.8.5最新正式版2026-09-30 · 2026-09-30 11:11 UTC

    Added

    • A traffic limit per tunnel. Set on the Iran end from the pencil in the card's bottom band, which now reads used / limit with a line that turns amber at 70% and red at 90% (no limit is the default, shown as ∞). The Traffic limit dialog has presets from 50 GB to 10 TB, any amount in GB or TB, and quick adds. The engine enforces it: the running total, in and out together, is checked four times a second and the tunnel goes offline the moment it reaches the limit — the card says Limit reached — and stays offline, service still up, until the limit is raised; then it comes back on its own within two seconds. The count is the tunnel's own total, which restarts, reloads and updates carry over and a backup restores, so nothing resets it but deleting the tunnel. /api/tunnel/quota; the limit is <name>.quota.json beside the config.

    • backpack proxy enable <socks5|http> <port> [--user U --pass P], proxy disable and proxy status — the menu's Built-in Proxy without the menu, and the line Manage → Built-in Proxy hands over for the kharej.

    • Applying a setup link again updates the tunnel it made. After an edit on the Iran end, sudo backpack link apply '…' on the kharej rewrites its end of that tunnel in place — same name, the new transport and port — instead of refusing because the tunnel exists. link apply also reads better: a boxed report with the result, and "waiting for the Iran server" printed while it waits, not after.

    • Web panel: the dock is now Overview · Connection test · Tunnels · Terminal · Manage. Connection test runs the Iran side of the menu's Connection Test from the browser — start it, copy the one sudo backpack link apply '…' line (or the install-and-test line for a kharej without Backpack), and watch every transport's row fill live, ending in the best-settings card. Terminal is a root shell on the server (xterm.js, vendored under panel/js/vendor, MIT): browser sessions only — never an API token — same-origin WebSocket, at most four at once, and every one opened is written to the audit record and the alert feed. The shell survives moving between sections. Manage carries Auto Refresh (with a 24-hour dial of when the restarts land), the Built-in Proxy (enable, disable, and a test that speaks the SOCKS5/HTTP handshake with the configured credentials) and File Locations (grouped, filterable, with size, item count and age). Servers is out of the dock for now; its route still answers.

    • Web panel: the rest of the menu's setup, backup, update and panel screens. Setup link (tunnel card → ⋯ → Setup link…, and at the end of Add tunnel when only this end is built) shows the link with the kharej's sudo backpack link apply '…' line and the install-and-set-up line. Maintenance → Backup lists the archives kept in the backups folder with Back up now, Test (the menu's Test A Restore — changes nothing), Download, Restore and Delete, and sets and tries the off-site copy command. Maintenance → Update installs from an uploaded backpack_linux_<arch>.tar.gz (+ SHA256SUMS), refusing another architecture's archive, and Restore points can roll back. Settings → Panel access moves the address path (random, your own, none), issues a new login code and restarts the panel, following it to its new address. The fleet key stays in the menu only, on purpose (see menu/backup.go).

    • Web panel: Add tunnel no longer needs a managed server. It is the CLI wizard again — Iran or kharej, then reverse or direct (as two cards, not a small switch), then the tunnel, performance, optional and done — and it builds this server's end only, ending on the setup link for the other one. The token is made here and carried by the link; the reverse Iran side's token field had no name, so it was never sent.

    • Connection Test (main menu, option 0): which transports actually hold between two servers. Star

  2. v1.8.4Backpack v1.8.42026-09-26 · 2026-09-26 09:09 UTC
    查看更新说明

    Changed

    • A direct tunnel is set up from the Iran server, and the kharej server pastes one line. The Iran wizard asks short questions, in order: Kharej IP Or Domain, Tunnel Port, Forwarded Ports (Blank For TUN), Tunnel Name, Security Token — generated on the Iran side, press Enter — UDP, Error Correction (FEC), the preset and fine-tuning; the tunnel addresses are picked for it. The paragraphs of explanation between the questions are gone. The summary before Create This Tunnel is one short block — Direct PCK, interface, where it dials, forwarded ports, tuning, config file — with the Setup Link (backpack://…) under it. On the kharej server, after the carrier: Setup Link (paste the line; only a name is asked) or Manual. Each kharej behind one Iran server gets its own link. By hand, the kharej side no longer invents a token: it has to be the Iran server's.
    • The reverse wizard works the same way. Iran asks, in order: Iran IP Or Domain (the detected public IP is the default), Tunnel Port, Forwarded Ports, Tunnel Name, Security Token (generated — press Enter), UDP, then the transport's own questions — TLS Certificate and Simple Token Auth for WSS, TCP Flag Pattern for PCK, Send Real Client IP (PROXY Protocol) where it can be carried — the preset and fine-tuning. One short summary (Reverse TCP, where it listens, what kharej dials, where each forwarded port lands on kharej) shows the Setup Link before Create This Tunnel. On kharej, after the transport: Setup Link (paste; only the name is asked) or Manual, whose token prompt no longer offers the meaningless default backpack. The link now also carries simple auth, the smux version and, for KCP, the exact error-correction pair, so a kharej built from it cannot disagree with Iran on them. The udp transport, whose forwarded ports are UDP anyway, is no longer asked about UDP. Tested through the menus on all eleven reverse transports.
    • The direct carriers are listed as xDi, PCK, UDP, Quic, IP Spoofing, SNI Spoofing, in that order. xDi, PCK, UDP and Quic use the setup-link wizard; UDP's several-sockets question is short too, and the summary names the port range the kharej must open. IP Spoofing and SNI Spoofing keep the classic wizard — both ends by hand, the token made on kharej — since their answers belong to the route and are worked out on each machine.
    • The setup link now carries everything the two ends must agree on. The GRE key, the exact error-correction pair, the MTU, the TCP segment cap and automatic MTU were missing, so a tunnel built from a link — or by the panel on a managed server — could differ between its two ends. Measured through the menus with one Iran and three kharej (Germany, USA, Finland on ports 1245, 3294 and 3190): 1 GiB crossed each tunnel at the same time at about 1 Gbit/s apiece, on pck and on xdi, with one session per tunnel and no drop after an idle minute.
    • The sign-in pages look like the panel. The password and two-factor pages use the panel's own palette, glass card, mark and accent-bar ground, and follow its light or dark theme and its accent — they used to be a fixed red page that knew none of the panel's current accents. A wrong password or code now says so under the field instead of the page silently reappearing.
    • The panel installs as an app on a phone again. Behind a trusted certificate (Let's Encrypt or your own), Android and desktop Chrome offer to install it — an Install app button appears in the header — and it opens full screen from the home screen, clear of the notch and the home indicator. On an iPhone the same button explains Share → Add to Home Screen. The rebuilt panel had stopped linking the manifest and registering the service worker, so no browser ever offered it. The app icon, the sign-in pages and
  3. v1.8.3Backpack v1.8.32026-09-25 · 2026-09-25 17:27 UTC
    查看更新说明

    Added

    • Several kharej servers behind one Iran server, on a direct layer-3 tunnel. The Iran side of a direct tunnel dials, so each kharej is its own tunnel — its own interface and 10.10.N.0/30, any carrier, pck included — and one forwarded port can now be served by all of them. Each new connection goes to the kharej with the fewest connections open, so bandwidth adds up: two kharej on pck, each limited to 300 Mbit/s, gave 267 Mbit/s apiece and 535 Mbit/s together on the shared port. The wizard offers the sharing when the second kharej is given a port the first already forwards, the panel does it on its own, and the Iran summary now says which tunnel addresses the kharej has to enter (the kharej wizard proposed the first block free on its own machine, which for a second kharej was the wrong one, and the tunnel came up carrying nothing).

    Changed

    • pck is much faster. Measured on a loopback pair in network namespaces, three runs each:

      • Layer-3 pck, 16 parallel downloads: 742 → 1,300 Mbit/s, with 60% less CPU on the Iran side and 43% less on kharej. One stream: 970 → 1,390.
      • Reverse pck, 16 parallel downloads: 545 → 631 Mbit/s.

      Three causes, found by profiling a loaded tunnel:

      • Every segment sent or received read the clock to stamp a "last seen" time that nothing ever read, and built a string to find its peer. On a VM whose clock is not the cheap kind that was 15% of the CPU on its own. Both are gone, which is also what reverse pck gains.
      • The layer-3 tunnel wrote received packets to its interface one at a time. It now reads the pck socket in batches (recvmmsg) and writes a whole batch to the interface in one call, which lets the kernel coalesce a flow's segments into large ones before its receive path sees them.
      • Sending took one syscall per segment; a batch now goes out in one (sendmmsg), with one clock read for the batch.

    • xdi (ICMP) is twice as fast on a direct layer-3 tunnel: 16 parallel downloads 543 → 1,150 Mbit/s, 16 uploads 627 → 1,325, one stream 582 → 1,112. It reads and sends its echoes in batches, as pck now does.

    • The xdi server no longer sends every upload back. The client's data travels in Echo Requests, and the server's kernel answered each one with an Echo Reply carrying the whole payload. The client discarded them, but they had already crossed the path: every byte uploaded through xdi left the server twice. One iptables rule now drops exactly those — the tunnel's tag with the client's direction byte — and nothing else: pings to the server and across the tunnel still answer. With the batching, the server's CPU for a 16-stream upload fell from 17 to 7.7 CPU-seconds. Where the u32 module is missing the rule does not install and the tunnel works as before.

    • The speed test measures with 8 connections at once instead of one. One TCP connection measures its own window, which on a long or lossy path is far below what the tunnel carries — and a tunnel carrying a VPN is never carrying one connection. The result says how many streams it used, and an older receiver on the far end measures the same way.

    Fixed

    • A dead backend on a shared layer-3 port stalled connections. The forwarder went round-robin and dialled every member in turn with a 10 s timeout, so with one of two kharej gone every second connection hung for ten seconds: ten connections took 50 s. A member whose dial fails is now set aside for 20 s, and while another is left to try a dial gives up after 3 s: the same ten took 3.1 s.
  4. v1.8.2Backpack v1.8.22026-09-24 · 2026-09-24 17:18 UTC
    查看更新说明

    Every finding of a section-by-section audit of the whole project, and the mechanism that lets a fix like these reach a server that already exists.

    That mechanism is the part worth reading first. Two of the fixes below change nothing for a server that already exists, because what they correct is not in the binary: it is a permission bit on a file written once at setup, and a kernel value written once and never read back. ip_local_port_range is the case that proves the point. It was corrected in v1.8.1, Health Check was taught to report it, and the engine went on widening it back on every single tunnel start — so an operator could optimize the machine, pass its own check, and be wide again the moment a tunnel restarted. An update now corrects the machine as well as the binary.

    Verified on a real tunnel, not only in tests: all six layer-3 carriers — udp, quic, pck, sni, xdi and spoof — carried a 5 MB payload byte-identical over a TUN device in a network namespace, with no packet loss on a ping across the tunnel. That path had never been exercised end to end before, because the raw-socket carriers need capabilities a test process does not have.

    Security

    • Any Telegram admin with write access could read the panel password from the Web UI screen, or take a backup that carries it — and the panel password is everything, including who else gets in. The same gap the panel's write tokens had. Both are now the bot owner's alone; added admins keep running the tunnels.

    • A release signature did not say which release it was for. It covered the checksum list, which names archives but not versions, so a mirror or proxy — which is how restricted networks fetch releases — could serve an older release's genuine archive, checksums and signature under a newer tag, and every updater would verify and install it: a downgrade signed by the publisher. The tag is now part of what is signed. No release carried a signature before this one, so nothing already installed depends on the old form.

    • The reverse QUIC transport handed its token to anything that terminated the TLS. The client does not verify the server's certificate, and then sent the token as its control claim and on every data stream, and the server echoed it back. It now proves the token with an HMAC over keying material exported from the TLS session, as WSS already did, and the server answers with a proof of its own; a man in the middle holds a different session with each end and gets nothing usable. A test puts a real QUIC man in the middle between the two and checks the tunnel does not come up and the token never crosses it — it did both before. Upgrade the Iran server first: a new server still accepts an older client's token, a new client never sends one.

    • A recorded layer-3 handshake could be replayed for ever. Protocol v2 puts a monotonic timestamp inside the dialler's encrypted handshake payload and the listener refuses one that does not advance (WireGuard's rule); once it has seen one, it refuses the older, untimestamped handshake too. It interoperates with v1.8.1 in both directions: against an old listener the dialler falls back on that listener's own authenticated answer — never on silence, so the path cannot force it — and retries v2 every half hour. Verified against a real v1.8.1 binary each way.

    • The audit record is a hash chain. Editing or deleting a line is shown at the top of the record, and every line forwarded to Telegram carries the head of the chain, so even a consistent rewrite disagrees with the copies off the machine.

    • A write API token could make itself admin. /api/tokens and /api/audit were guarded at admin, but everything else that decides who gets in sat at write: the panel password, the second factor, the signed-in devices, the Telegram admin list, the panel's port and certificate, and backup export and restore. A backup carries t

  5. v1.8.1Backpack v1.8.12026-09-15 · 2026-09-15 08:57 UTC
    查看更新说明

    Added

    • Managed Server cards now show packet loss and round-trip time with background fleet-wide probing.
    • Redesigned Managed Server cards with compact identity information and CPU/Memory usage gauges.
    • Clear visual states for reachable, unreachable, and pending Managed Servers.
    • Tunnel charts now support Live, 24h, 7d, and 30d windows with matching rate/total units and trend indicators.
    • Added local bind address support for forwarded ports and port ranges across reverse transports.
    • Added dedicated Port Mappings documentation and cross-links.
    • Restored a subtle masked dotted chart background for improved visual hierarchy.

    Improved

    • Managed Server pages now render immediately from cached information instead of waiting for SSH responses.
    • Managed Server CPU usage is now sampled over a real measurement interval.
    • Fleet cards update in place without unnecessary re-renders or animation flicker.
    • Overview daily traffic charts now refresh periodically and stay synchronized with current totals.
    • Server location, ISP, and IPv4 detection now prefer addresses actually assigned to the server, with fallback detection clearly marked as inferred.
    • Forwarded-port parsing is now shared across transports and supports bind addresses with port ranges.

    Fixed

    • Fixed excessive memory usage in UDP transport caused by oversized per-connection queues.
    • Fixed persistent memory and socket leaks across UDP, TCP, WS, and QUIC after tunnel restarts.
    • Fixed connection cleanup after failed writes and stale flow removal during address reuse.
    • Fixed forwarded ports crashing the entire tunnel/process when a port was already occupied.
    • Fixed TCP and TCP Mux tunnels becoming permanently locked to stale control channels after reconnects.
    • Fixed kernel ephemeral-port tuning causing service ports to fall inside the ephemeral range.
    • Fixed updates failing to refresh previously applied kernel tuning.
    • Fixed Health Check incorrectly reporting outdated ephemeral port ranges.
    • Fixed tunnel chart areas rendering unwanted outlines.
    • Fixed layer-3 tunnels with multiple UDP carrier paths completing handshakes but carrying no traffic.

    Notes

    • UDP per-connection queue depth is now 256, significantly reducing idle and high-concurrency memory usage.
    • Kernel tuning now preserves the system's normal ephemeral port range and reserves configured tunnel ports.
    • Bind addresses control where listeners accept connections but do not solve asymmetric routing; policy routing may still be required on multi-NIC hosts.
    • Existing tunnel configuration and wire protocol behavior remain unchanged.

用户点评

登录用户的真实使用记录，可按版本和硬件筛选
共 0 条

    还没有人点评。第一个说出真实体验的人最有价值。

    README 原文

    未翻译
    在 GitHub 打开

    What is BackPack?

    BackPack is a high-performance tunnel engine for connecting Iran ⇄ abroad (kharej) servers.

    It is written in Go and distributed as a self-contained binary with:

    • Interactive CLI
    • Web monitoring panel
    • Multiple tunnel transports
    • Full IP direct tunneling
    • Automatic failover and transport fallback
    • Health checks and route diagnostics
    • Backup, rollback and verified updates
    • Telegram monitoring
    • Multi-server management

    BackPack is designed for routes where connectivity is not something you can simply assume will stay healthy.

    Instead of depending on one protocol or one path, it gives you several transport and recovery strategies and lets you measure the route before choosing one.

    How it works

    Reverse tunnel

    The normal BackPack tunnel is a reverse tunnel:

                        INTERNET
                       │
                       │ user traffic
                       ▼
                ┌──────────────┐
                │ IRAN SERVER  │
                │              │
                │ Exposed port │
                └──────┬───────┘
                       │
                       │ BackPack tunnel
                       │
                       ▼
                ┌──────────────┐
                │ KHAREJ SERVER│
                │              │
                │ Real service │
                └──────────────┘

    The direction is important:

    KHAREJ ───────────────▶ IRAN
          tunnel

    The kharej server dials the Iran server, while user traffic enters through the Iran server and is forwarded to the service on kharej.

    ServerSetupRole
    IranSetup IranListens for the tunnel and exposes forwarded ports
    KharejSetup KharejDials Iran and forwards traffic to the real service

    This means:

    • The kharej server does not need an inbound tunnel port.
    • The Iran server needs the tunnel port open.
    • The Iran side should be configured first.
    • The kharej side needs the Iran address, tunnel port and token generated by the Iran side.

    The tunnel port and the forwarded ports are different things. The tunnel port carries BackPack itself; forwarded ports are the ports your users connect to.

    For the complete explanation, see Before you start.

    Direct tunnel

    BackPack also supports a direct tunnel, where Iran initiates the connection to kharej.

    IRAN ─────────────────────────▶ KHAREJ
             tunnel

    The current Setup → Direct wizard builds BackPack's full layer-3 tunnel.

    Instead of forwarding individual connections, it creates a private point-to-point network interface between the two machines and carries complete IP packets through it.

    ┌──────────────┐                  ┌──────────────┐
│ IRAN         │                  │ KHAREJ       │
│              │                  │              │
│ 10.10.0.1    │══════════════════│ 10.10.0.2    │
│              │    BackPack      │              │
└──────────────┘                  └──────────────┘

    The direct tunnel uses:

    • GRE encapsulation
    • Noise encryption
    • Automatic MTU handling
    • Multiple carrier options
    • Full IP routing

    Set up the Iran server first: Setup Iran → Direct → carrier. Its summary, right before Create This Tunnel, shows a one-line setup link (backpack://…) and, under it, one command that installs Backpack on a fresh kharej and builds the tunnel from that link; on a kharej that already runs Backpack choose Setup Kharej → Direct → the same carrier → Setup Link, or run backpack link apply '<link>'. The token, addresses and tuning come across in the link. For several kharej servers behind one Iran server, repeat it once per kharej — each gets its own link.

    See Direct layer-3 tunnel.

    The older stream-based [direct] engine still exists for existing configurations, but the current wizard builds the layer-3 direct tunnel.

    Before you start

    There are four things responsible for most first-time setup problems:

    1. The roles

    Users
  │
  ▼
Iran ────────────────▶ Kharej
       BackPack          │
                        ▼
                    Real service

    2. The token

    The Iran side generates a random 64-character token.

    Both ends must use the same token.

    A mismatch can look like a dead tunnel, especially on encrypted transports where the server may intentionally not respond.

    3. Port mappings

    For example:

    443

    means:

    Iran :443
   ↓
Kharej 127.0.0.1:443

    while:

    443=127.0.0.1:2096

    means:

    Iran :443
   ↓
Kharej 127.0.0.1:2096

    You can also use explicit backend addresses, multiple backends and port ranges.

    See Port mappings.

    4. UDP

    Forwarded ports carry TCP by default.

    UDP forwarding is a separate per-tunnel setting.

    Enable it when the service behind the tunnel requires UDP, such as:

    • Xray / 3x-ui
    • Shadowsocks UDP
    • WireGuard
    • DNS
    • Games

    See Forwarded UDP.

    Quick Start

    1. Install

    On both servers:

    bash <(curl -fsSL https://raw.githubusercontent.com/AminMGMT/BackPack/main/install.sh)

    Then:

    sudo backpack

    The installer downloads the release for the server architecture, verifies its published checksum, installs it and opens the CLI.

    Supported release architectures currently include:

    x86_64  → amd64
aarch64 → arm64

    If the server cannot reach GitHub, BackPack also supports a completely offline installation.

    See Installation.

    2. Configure the Iran server

    sudo backpack

    Then:

    1. Setup Iran
→ Reverse
→ Transport
→ Iran IP Or Domain (the detected one is the default)
→ Tunnel Port
→ Forwarded Ports
→ Tunnel Name
→ Security Token (generated — press Enter)
→ Carry UDP As Well As TCP
→ the transport's own questions (certificate for WSS, flags for PCK, …)
→ How Should The Tunnel Be Tuned?

    The summary before Create This Tunnel shows a one-line Setup Link (backpack://…). Copy it.

    For a first deployment, TCP is the simplest starting point.

    3. Configure the kharej server

    sudo backpack

    Then:

    2. Setup Kharej
→ Reverse
→ Same transport
→ Setup Link → paste the link → Tunnel Name → Create This Tunnel

    Manual is there too: Iran IP, the same tunnel port, a name, the same token, the same preset.

    4. Check the tunnel

    Use:

    Manage → Status

    Then:

    Manage → Health Check

    If you are unsure which transport to use:

    Manage → Link Test

    Link Test measures the route over TCP, including latency, jitter and packet loss, and recommends a suitable transport.

    See Choosing a transport.

    Which transport should I use?

    If you don't know where to start, use this:

    SituationStart with
    Clean / ordinary routeTCP
    Many short-lived connectionsTCP Mux
    TCP is filtered or unstableTCP + Stealth
    TCP connects but stalls, resets or gets throttledTCP + PCK
    You specifically need raw UDPUDP
    Lossy route / real-time traffic / gamingUDP + KCP + FEC
    You want to test QUICUDP + QUIC
    HTTP/WebSocket traffic is usefulWS / WS Mux
    HTTPS-style traffic is requiredWSS / WSS Mux
    TCP and UDP are filtered but ICMP worksxDi (ICMP)
    Inbound access to Iran is unavailableDirect tunnel

    The easiest way to choose is:

    Kharej
  ↓
Manage → Link Test
  ↓
Measure route
  ↓
Get recommendation

    See Choosing a transport and all transports.

    Transport overview

    BackPack currently provides twelve reverse-tunnel transports.

    TransportFamilyEncryptionPROXY v2Requirements
    TCPTCP—✓—
    TCP MuxTCP—✓—
    TCP + StealthTCPNoise✓—
    TCP + PCKTCPToken-derived✓Linux + root
    UDPUDP——UDP open
    UDP + KCP + FECUDPToken-derived✓UDP open
    UDP + QUICUDPTLS 1.3✓UDP open
    WSWebSocket———
    WS MuxWebSocket—✓—
    WSSWebSocketTLS—Certificate
    WSS MuxWebSocketTLS✓Certificate
    xDi (ICMP)ExperimentalToken-derived✓Linux + root + ICMP

    TCP

    Plain reliable TCP.

    Low overhead and the simplest starting point on a clean route.

    TCP Mux

    Multiplexes multiple logical connections over a small pool of TCP connections.

    Useful for services that create many short-lived connections.

    TCP + Stealth

    TCP wrapped in a Noise record layer.

    The handshake and encrypted stream do not use a TLS ClientHello or a recognizable application protocol header.

    Useful when plain TCP is being identified, filtered or killed.

    TCP + PCK

    Builds TCP segments without using the kernel's normal TCP connection state.

    Useful when normal TCP connects but later stalls, resets or gets throttled.

    Requires Linux and root on both ends.

    UDP

    Raw UDP transport with minimal overhead.

    There is no reliability or ordering layer.

    UDP + KCP + FEC

    Reliable, ordered transport over UDP with forward error correction.

    Designed for routes where packet loss makes TCP back off too aggressively, and for latency-sensitive traffic.

    UDP + QUIC

    QUIC over UDP with TLS 1.3, multiplexing, congestion control and loss recovery.

    It is available for testing, but BackPack's route testing does not generally recommend it over KCP for lossy Iran routes.

    WS / WS Mux

    WebSocket transport for routes where HTTP traffic is useful or where the tunnel needs to sit behind a CDN.

    WS Mux adds multiplexing and PROXY protocol support.

    WSS / WSS Mux

    WebSocket over TLS.

    WSS can use a real certificate and Chrome-style TLS behavior and can provide a decoy site for probes.

    xDi

    Carries the KCP transport inside ICMP echo packets instead of UDP.

    Designed for the specific case where TCP and UDP are filtered but ICMP remains available.

    It is a last-resort transport rather than the normal starting point.

    See the complete Transport reference.

    Forwarded UDP

    UDP forwarding is independent of the transport carrying the tunnel.

    For example:

    Iran :443/tcp + :443/udp
        │
        ▼
BackPack
        │
        ▼
Kharej :443/tcp + :443/udp

    This is useful for:

    • Xray / 3x-ui
    • WireGuard
    • DNS
    • Games
    • Other services that require UDP

    UDP forwarding is off by default.

    See Adding UDP to a tunnel.

    Reliability

    BackPack is built around routes that can change or fail.

    Backup addresses

    A tunnel can have multiple server addresses.

    BackPack can:

    • automatically fail over between addresses
    • health-score available addresses
    • load-balance across healthy addresses

    See Failover & load balancing.

    Transport fallback

    A tunnel can also have a fallback chain.

    For example:

    transport = "wss"

fallback_transports = [
  "quic",
  "kcp",
  "tcpmux"
]

    If the active carrier stops getting through, BackPack can move through the configured fallback chain.

    See Transport fallback.

    Self-healing

    BackPack includes a watchdog that detects stopped or stalled tunnels and performs recovery.

    Services are managed through systemd and survive reboots.

    Automatic rollback

    Updates and relevant configuration changes can create restore points and roll back when the tunnel does not return successfully.

    Diagnostics

    BackPack includes diagnostics directly in the CLI.

    Link Test

    Measures:

    • latency
    • jitter
    • packet loss

    It also recommends a transport for the measured route.

    Health Check

    Checks the server, panel and tunnels and provides a suggested fix when it detects a problem.

    Tunnel Metrics

    Provides tunnel-level statistics including traffic, connections and transport-specific metrics such as KCP retransmissions, loss and FEC repairs.

    See:

    Performance

    BackPack provides four performance presets:

    • Balance
    • Turbo
    • Aggressive
    • Throughput

    The first three tune the queues and transport behavior for a full IP tunnel; Throughput is intended for maximizing sustained transfer.

    BackPack also includes kernel/network optimization through the CLI.

    See Performance presets.

    Security

    BackPack provides several security mechanisms depending on the transport and deployment mode.

    Encrypted transports

    Encrypted tunnel options include:

    • TCP + Stealth
    • TCP + PCK
    • UDP + KCP + FEC
    • UDP + QUIC
    • WSS
    • WSS Mux
    • xDi

    On plain transports such as TCP, TCP Mux, UDP, WS and WS Mux, the tunnel credential itself is not encrypted by the transport.

    Web panel security

    The Web Panel supports:

    • Password authentication
    • Two-factor authentication
    • Recovery codes
    • Scoped API tokens
    • Authorization records

    See Access control.

    Verified releases

    Release archives are verified against the published SHA-256 checksum.

    An archive that cannot be verified is refused rather than installed.

    See Updates & rollback.

    Real client IP

    Backends normally see the connection as coming from the tunnel itself.

    BackPack can instead send the original client address using PROXY protocol v2.

    This allows applications and panels behind the tunnel to see the real client IP and keep per-user/device limits working.

    Supported transports and limitations are documented in:

    Real client IP / PROXY protocol v2

    Web Panel

    BackPack includes a monitoring-focused web dashboard.

    It provides:

    • CPU usage
    • RAM usage
    • Disk usage
    • Traffic
    • Tunnel state
    • Real ping
    • Logs
    • Backup and Telegram settings
    • Panel security settings

    The panel listens on port 7777 by default.

    Iran server
    │
    └── Web Panel :7777

    The panel is primarily for monitoring and management around the deployment; tunnel creation and detailed tunnel configuration remain available through the CLI.

    It also supports:

    • HTTPS
    • Custom certificates
    • Two-factor authentication
    • Recovery codes
    • API access control

    See:

    Managed servers

    The Web Panel can register remote servers as managed nodes.

    Once registered, BackPack can use the panel to build and manage both ends of a tunnel without requiring you to repeat the entire SSH setup manually.

    Managed servers can be:

    • registered
    • edited
    • tested
    • used to create tunnels
    • started
    • stopped
    • restarted
    • removed

    See Managed servers.

    Telegram monitoring

    BackPack can send status and alert messages through Telegram.

    The built-in Telegram integration can relay its connection through a tunnel peer, allowing Telegram monitoring from environments where direct Telegram access is unavailable.

    It supports:

    • periodic status reports
    • tunnel status
    • resource alerts
    • recovery messages
    • monitoring events

    See:

    Backup & Restore

    BackPack can create a portable backup containing the important deployment state, including:

    • tunnel configurations
    • panel settings
    • panel password
    • Telegram settings
    • TLS certificates
    • scheduled tasks

    Backups are stored as .tar.gz archives.

    They can also be restored onto another machine.

    See Backup & Restore.

    Updates

    BackPack can update itself from the GitHub release system.

    The update process:

    1. Detects the available release.
    2. Downloads the architecture-specific archive.
    3. Verifies the published SHA-256.
    4. Installs the release.
    5. Uses restore points and recovery logic if the updated tunnel does not return successfully.

    Updates can also use a tunnel peer when the server itself cannot reach GitHub.

    If neither direct access nor a tunnel path is available, BackPack supports offline updates.

    See Updates & rollback.

    Offline installation

    BackPack does not require the VPS itself to have GitHub access.

    Download the release from a machine with internet access and copy it to the server.

    For example:

    scp install.sh SHA256SUMS backpack_linux_amd64.tar.gz root@SERVER_IP:/root/

ssh root@SERVER_IP \
  "cd /root && sudo bash install.sh"

    Or install manually after verifying the checksum:

    sha256sum backpack_linux_amd64.tar.gz

tar xzf backpack_linux_amd64.tar.gz

mkdir -p /etc/backpack /root/BackPack/backups

install -m 0755 backpack /usr/local/bin/backpack

echo /root/BackPack > /etc/backpack/install_path

sudo backpack

    See Installation.

    Configuration & operations

    For operators who need more than the basic setup, BackPack documents its internal configuration and operational behavior separately.

    CLI

    CLI menu reference

    Complete reference for:

    • Setup Iran
    • Setup Kharej
    • Direct setup
    • Tunnel management
    • Built-in proxy
    • Backup & Restore
    • Web Panel
    • Optimize
    • Telegram
    • Updates
    • Fine Tune
    • File locations

    Configuration

    Configuration reference

    Generated from the configuration declarations and documents every configuration key BackPack reads.

    Server layout

    /root/BackPack
/root/BackPack/backups
/etc/backpack
/usr/local/bin/backpack

    See Server layout.

    Documentation

    BackPack intentionally separates setup tutorials from technical reference.

    Tutorials

    The tutorial/ directory explains how to actually build a tunnel, step by step, following the CLI wizard.

    Start here

    Reverse transports

    Special deployments

    Documentation reference

    Architecture & internals

    Transports & networking

    Operations

    Reliability & maintenance

    Management & security

    Development

    Every documentation page includes a Persian summary where applicable.

    Screenshots

    CLI

    Web Panel

    Tunnel Management

    Telegram Bot

    Support & Community

    If BackPack is useful to you:

    • Star the repository
    • Report bugs through GitHub Issues
    • Contribute improvements
    • Join the Telegram community

    Telegram

    Contributing

    Pull requests, bug reports and technical improvements are welcome.

    Before contributing:

    1. Read CONTRIBUTING.md.
    2. Check the relevant documentation.
    3. Keep changes focused.
    4. Add or update tests where appropriate.
    5. Update documentation when behavior or configuration changes.

    For the release process, see Releasing.

    License

    Copyright © 2026 Amin Mohammadi (AminMGMT).

    BackPack is released under the GNU Affero General Public License v3.0 (AGPL-3.0).

    See:

    You may use, study, modify, redistribute and build a business on BackPack under the terms of the license.

    Additional attribution and trademark conditions apply.

    Attribution

    Modified versions must keep this line, unaltered, in their README (and in NOTICE):

    Based on BackPack by Amin Mohammadi (AminMGMT)
https://github.com/AminMGMT/BackPack

    Name & logo

    BackPack, its name and logo are not licensed as part of the source code.

    Forks should use their own name and branding.

    It is permitted to truthfully state that a project is based on or compatible with BackPack.

    See TRADEMARK.md for the complete terms.

    相关项目

    同分类里 star 最高的项目
    对比全部 →
    frp
    fatedier·Go

    一款用 Go 编写的高性能反向代理，能把 NAT 或防火墙后面的本地服务安全暴露到公网，常用于内网穿透和远程访问。

    内网穿透+4内网穿透 / 隧道
    110508+4015kv0.72.02026-11-10 09:44 UTC
    tailscale
    tailscale·Go

    基于 WireGuard 的零配置虚拟组网工具，把设备连成加密私有网络，支持 SSO、OAuth 和 2FA 登录，省去手动配置 VPN 的麻烦。

    虚拟组网+4内网穿透 / 隧道
    38873+1343.5kv1.104.52026-11-10 10:39 UTC
    ngrok
    inconshreveable·Go

    Unified ingress for developers

    内网穿透 / 隧道
    243834.2k2024-04-26 18:11 UTC
    awesome-tunneling
    anderspitman·Python

    汇总 ngrok、Cloudflare Tunnel、Tailscale、ZeroTier 等内网穿透与隧道方案的开源清单，重点收录可自托管的替代工具，方便按需选型。

    内网穿透+4内网穿透 / 隧道
    22035+111.1k2026-11-02 15:14 UTC