When Cloudflare Tunnel or Argo Tunnel is in the path, some rule-based proxy apps need *.argotunnel.com treated as a real IP target and excluded from the proxy chain.

In Loon-style configs, that usually means putting *.argotunnel.com in real-ip and skip-proxy. The goal is simple: resolve the tunnel hostname normally and connect to it directly instead of bouncing that tunnel traffic through another proxy layer.

For example, in Loon you may need this in `[General]`: `real-ip = *.argotunnel.com` `skip-proxy = *.argotunnel.com`

If your current network cannot reach *.argotunnel.com directly, do not keep it in skip-proxy. Route it through a stable proxy policy instead, or use a custom relay / Tailscale path.

That error usually means the phone could not reach the host inside the QR payload at all, before Vibelet received any HTTP response.

Common causes are: the phone and computer are not on the same reachable network, the QR points to a LAN or .local address that the phone cannot resolve, Local Network permission was denied on iPhone, or a proxy app intercepted the tunnel / relay domain incorrectly.

If you are using a remote tunnel, make sure the relay hostname itself is reachable. If you are using LAN-only pairing, try the computer LAN IP directly or rerun Vibelet with the right host / fallback hosts.

The pairing QR is intentionally short-lived and one-time-use. That keeps the pairing flow simple without leaving a reusable open window behind.

If it expires, just run `npx vibelet` again on your computer and scan the fresh QR code. If this phone was already paired before, reconnecting from the saved device entry may still work.

Use `npx vibelet --local` when your phone and computer are already on the same LAN and you do not want Vibelet to use the default remote tunnel for that run.

Use plain `npx vibelet` when you want the QR code to be remote-ready by default. That is the better default when you are not sure whether the phone will stay on the same local network.

A custom relay means you already have a public tunnel URL, such as Cloudflare Tunnel or ngrok, and pass it to Vibelet with `--relay=https://...`.

Tailscale is different: there is no public relay URL in Vibelet. Instead, you tell Vibelet the machine Tailscale IP with `--host=<tailscale-ip>`, and your phone must also be logged into the same tailnet.

The official Tailscale GUI (the macsys build) uses macOS NetworkExtension and grabs the default route. Loon / Surge are also NetworkExtension-based, so the two fight over routing — once Tailscale is on, the proxy tool's TUN effectively stops and outbound traffic-shaping breaks.

Fix: switch to the open-source standalone `tailscaled`, which uses a plain `utun` interface instead of NetworkExtension and coexists with Loon cleanly.

Steps: quit `Tailscale.app`, drag it to Trash from Finder (this triggers the system-extension uninstall prompt — `rm` does not), then run: `brew install tailscale` `sudo tailscaled install-system-daemon` `sudo tailscale up --advertise-exit-node`

On the Loon / Surge side, keep Tailscale traffic out of the proxy by adding `100.64.0.0/10` to `skip-proxy` and `bypass-tun`, plus direct rules for `*.ts.net` and `IP-CIDR,100.64.0.0/10,DIRECT,no-resolve` near the top of the rule list.

On iOS, Tailscale and Loon are mutually exclusive (system-level NE limit, only one tunnel at a time). The usual workaround is to run the Mac as a Tailscale exit node and have the phone select it — outbound traffic from the phone then flows through the Mac's Loon.