Airpipe

Sanyam-GMIT活跃维护

在终端里扫个二维码就能和手机或电脑互传文件,端到端加密,中继服务可自托管,省去登录和配置的麻烦。

Send files between your terminal and any phone or computer by scanning a QR code. End-to-end encrypted, with a self-hostable relay.

v5.0.0发布于 2026-11-01 00:15 UTC361star +1 / 7 天16fork同步于 2026-11-10 23:59 UTC

怎么上手

由 README 提炼,执行前请确认
docker run -p 8080:8080 ghcr.io/sanyam-g/airpipe-relay
curl -sSL https://airpipe.sanyamgarg.com/install.sh | sh
硬件要求按 README 说明

README 未说明;仅提到中继是约 15 MB 的 Go 二进制,可用 Docker 运行,未提及 GPU 或显存要求

有 Docker 镜像
下载:源码 zip·GitHub Releases(安装包)本站不镜像安装包

项目说明

由 README 自动翻译提炼

扫个码或报个口令,就能在终端和任意手机电脑之间端到端加密传文件

在终端里扫个二维码就能和手机或电脑互传文件,端到端加密,中继服务可自托管,省去登录和配置的麻烦。

核心能力

  • 用四词口令派生密钥,通过 WebRTC 直连传输文件
  • NAT 打洞失败时自动回退到中继转发加密字节
  • 离线接收方可走 mailbox 模式,中继暂存加密文件 10 分钟
  • 提供自托管 Go 中继,单二进制内置网页 UI 和安装脚本
  • 口令经 PBKDF2 60 万次迭代派生 NaCl secretbox 密钥

容易踩的坑

v5 改了口令派生密钥的方式,无法与 v4 及更早版本互传,两端都要升级;自托管中继放在隧道或代理后面时必须设 AIRPIPE_TRUST_PROXY_HEADERS,否则所有访客共用一个限流额度;中继方仍可离线暴力猜口令,敏感文件建议用自己运行的中继

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

最近发版

5 个版本v5.0.0
  1. v5.0.0最新正式版2026-11-01 · 2026-11-01 00:15 UTC

    这个版本没有写更新说明。

  2. v4.4.02026-08-29 · 2026-08-29 16:54 UTC
    查看更新说明

    Self-hoster release. Most of it came from feedback in #25.

    • Minimal UI mode. AIRPIPE_MINIMAL_UI=true serves a plain send/receive page at / instead of the full site. The send page now has a receive passphrase box either way.
    • Private stats by default. /metrics and the live stats in /health need AIRPIPE_PUBLIC_STATS=true now. The limits the web pages read stay public.
    • Rate limiting can't be header-spoofed. Forwarding headers only count with AIRPIPE_TRUST_PROXY_HEADERS=true. Set it if your relay sits behind a tunnel or reverse proxy.
    • More reliable relay: fixed a duplicate-token upload race and rooms lingering after disconnect.
    • Smaller: dropped an unreachable page, ~800 lines of dead CSS, and unused packages.
  3. v4.3.02026-07-05 · 2026-07-05 21:23 UTC

    这个版本没有写更新说明。

  4. v4.2.02026-06-11 · 2026-06-11 13:15 UTC

    这个版本没有写更新说明。

  5. v4.1.62026-05-14 · 2026-05-14 23:41 UTC
    查看更新说明
    • airpipe help command for the full manual (also --help, -h).
    • Compact default usage when run without arguments.
    • --mode p2p|mailbox and --relay documented in CLI help.
    • README env vars rendered as a table.

    Thanks to @nimim0 for #15.

用户点评

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

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

    README 原文

    未翻译

    Send a file to any device by sharing a passphrase. It streams straight from one machine to the other, encrypted end to end. The relay that connects the two ends only handles encrypted data.

    AirPipe: the sender and receiver swap an encrypted offer and answer through the relay, then the file streams directly over WebRTC, encrypted end to end; the relay never gets the key

    Try it: airpipe.sanyamgarg.com

    How it works

    The sender picks a file and gets a passphrase like DUSK PINE ECHO GUST 42. The receiver enters it on the website, in the terminal (airpipe download DUSK PINE ECHO GUST 42), or by scanning the QR. The file then transfers directly between the two devices, encrypted the whole way.

    If the receiver is offline, the sender can use mailbox mode: the relay holds the encrypted file for 10 minutes until it's picked up. Same passphrase either way. The receiver never has to know which mode was used.

    Getting past NAT

    Two devices on home or office networks usually can't reach each other directly. Each one sits behind a router doing NAT, which drops connections it didn't expect, so neither side can just dial the other.

    AirPipe gets around this the way peer-to-peer normally does. Both devices open an outbound connection to the relay (outbound traffic passes through NAT freely), and the relay introduces them. Over that channel they run a short handshake, trading their public addresses and candidate routes until they find a path that punches through both NATs. Once it's open the file flows directly between them and the relay drops out.

    If the NATs are too strict to punch through, the transfer falls back to the relay, which forwards the encrypted bytes. They stay encrypted with the key derived from the passphrase.

    Self-host

    docker run -p 8080:8080 ghcr.io/sanyam-g/airpipe-relay
    

    One Go binary, ~15 MB image, bundling the web UI and install script. Or clone and docker compose up -d (ships an opt-in Watchtower auto-updater).

    Point the CLI at your relay with export AIRPIPE_RELAY=https://your-server.example (or --relay per call). Tunables, all optional:

    VarDefaultNotes
    PORT8080
    AIRPIPE_ALLOWED_ORIGINSsame-originExtra origins if pages serve from another domain. * = any.
    AIRPIPE_RATE_LIMIT_PER_MIN60
    AIRPIPE_MAX_UPLOAD_MB500Mailbox size cap.
    AIRPIPE_FILE_EXPIRY10mMailbox expiry (Go duration).
    AIRPIPE_MINIMAL_UIoffServe just the send/receive page at / instead of the full site.
    AIRPIPE_PUBLIC_STATSoffExpose /metrics and live stats in /health publicly.
    AIRPIPE_TRUST_PROXY_HEADERSoffRate-limit by Cf-Connecting-Ip / X-Forwarded-For. Set only behind a proxy that strips client-sent copies; required behind a tunnel, or every visitor shares one limit.

    /health (JSON) always reports the relay's limits, which the web UI reads, and its protocol version, which the CLI checks before each transfer. Uptime, active-file counts, and Prometheus /metrics stay private unless you set AIRPIPE_PUBLIC_STATS.

    CLI

    curl -sSL https://airpipe.sanyamgarg.com/install.sh | sh
    brew install sanyam-g/airpipe/airpipe
    go install github.com/Sanyam-G/Airpipe/v5/cmd/airpipe@latest
    

    Linux, macOS, Windows (amd64 + arm64). Self-update with airpipe update, or brew upgrade airpipe if you installed with Homebrew.

    v5 changed how a passphrase becomes a key, so v5 can't exchange files with v4 or older, and a v5 relay turns older clients away with a message to update. Update both ends.

    airpipe send report.pdf              # prompts: direct (P2P) or mailbox
    airpipe send file1.txt photos/       # multiple files / folders auto-zip
    airpipe download DUSK PINE ECHO GUST 42
    airpipe receive ./downloads          # wait for someone to send to you; prints a QR
    

    Browser to browser

    Open /live for a passphrase + QR, no install on either side. The receiver enters it at the homepage and the file transfers between the two browsers.

    Encryption

    Files are encrypted with NaCl secretbox (XSalsa20-Poly1305, 256-bit key). The direct path also runs inside WebRTC's DTLS.

    A passphrase is four words from a 1024-word list plus a number from 10 to 99, about 10^14 possibilities. The CLI and the browser both run it through PBKDF2-HMAC-SHA256 with 600,000 iterations and a fixed salt, then split the result with HKDF into the encryption key and the room tokens. The browser uses WebCrypto for this. Each transfer derives them once, which takes well under a second on a laptop.

    The relay sees a room token, both IP addresses, sizes and timing, and the ciphertext of mailbox and relayed transfers. It never receives the key. Links and QR codes carry the key after the #, and browsers don't send that part to the server. The key in a link is the same one the passphrase produces.

    The token comes from the passphrase, so whoever runs the relay can still guess passphrases offline and check each guess against the token. Each guess costs a full PBKDF2 run. On one high-end GPU, trying every passphrase takes on the order of 200 years, about 100 on average. An attacker with many GPUs and a specific target can still get there. For files that need more than that, use a relay you run or trust. A PAKE handshake, which would stop offline guessing, is planned.

    Stack

    Go relay (gorilla/websocket, pion/webrtc), embedded HTML/CSS/JS frontend (tweetnacl.js in the browser), Docker, optional Cloudflare Tunnel. Single static binary.

    Star History

    License

    MIT