Bug: librust_bridge.so not found at runtime

Package version: 2026.4.1350-1

System: Linux 7.0.10-1-cachyos, KDE Plasma 6.6.5

The GUI fails to start with Failed to load dynamic library 'librust_bridge.so' because /usr/lib/warp/lib is not in the dynamic linker search path.

Two changes needed:

1. Add to package() in the PKGBUILD:

install -Dm644 /dev/stdin "$pkgdir/etc/ld.so.conf.d/warp.conf" <<EOF
/usr/lib/warp/lib
EOF

2. Add ldconfig to the existing install hooks:

post_install() {
    ldconfig
    setcap ...
}
post_upgrade() {
    ldconfig
    setcap ...
}
post_remove() {
    ldconfig
    ...
}

Workaround until fixed: echo "/usr/lib/warp/lib" | sudo tee /etc/ld.so.conf.d/warp.conf && sudo ldconfig

The latest update introduced a missing dependency: libayatana-appindicator (provides libayatana-appindicator3.so.1). The new version of warp-taskbar is dynamically linked against it, but it is not listed in depends=(), so it doesn't get pulled in automatically on update. warp-taskbar fails immediately at launch with:

error while loading shared libraries: libayatana-appindicator3.so.1: cannot open shared object file: No such file or directory

Manually installing libayatana-appindicator resolves it. Please add it to the dependency list.

WARP not resolving private / Zero Trust DNS on Arch (returns public IPs)

Symptom

With warp-cli connect succeeding, hostnames protected by your Cloudflare Zero Trust policy (e.g., private AWS RDS, internal-only services) still resolve to their public IPs instead of the WARP gateway IP (in the 100.64.0.0/10 range). Result: connections to private resources time out even though the tunnel is up.

Quick check:

warp-cli connect
getent hosts <your-zero-trust-host>
# If it returns a public IP instead of 100.64.x.x / 100.80.x.x, you're affected.

Root cause

This package does not enable systemd-resolved, and Arch's default NetworkManager writes /etc/resolv.conf directly with whatever DNS servers it has — usually the ones from your Wi-Fi connection (8.8.8.8, your router, etc.).

The WARP daemon listens on 127.0.2.2 for split-horizon DNS, but nothing on the system actually queries it — so all DNS queries bypass WARP and hit your regular resolver, which returns the public IP.

On Ubuntu this works out-of-the-box because systemd-resolved is enabled by default and /etc/resolv.conf is already a symlink to its stub. On Arch you have to wire this up yourself.

Fix

# 1. Enable systemd-resolved
sudo systemctl enable --now systemd-resolved

# 2. Point /etc/resolv.conf at the resolved stub
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

# 3. Tell NetworkManager to delegate DNS to resolved
sudo install -d /etc/NetworkManager/conf.d
sudo tee /etc/NetworkManager/conf.d/dns.conf >/dev/null <<'EOF'
[main]
dns=systemd-resolved
systemd-resolved=true
EOF

# 4. Remove any hardcoded DNS on your active connection
#    (replace "MyWifi" with the name from `nmcli connection show --active`)
sudo nmcli connection modify "MyWifi" ipv4.dns "" ipv4.ignore-auto-dns no
sudo nmcli connection modify "MyWifi" ipv6.dns "" ipv6.ignore-auto-dns no

# 5. Restart NetworkManager and reconnect WARP so it re-registers its resolver
sudo systemctl restart NetworkManager
warp-cli disconnect && sleep 2 && warp-cli connect

Verify

resolvectl status | grep "DNS Server"
# Should show 127.0.2.2 / 127.0.2.3 on the CloudflareWARP link.

resolvectl query <your-zero-trust-host>
# Should now return an IP in 100.64.0.0/10 instead of the public one.

Optional: keep a public DNS fallback when WARP is off

Add it to systemd-resolved (not to NetworkManager) so it doesn't clash:

sudo tee /etc/systemd/resolved.conf.d/fallback.conf >/dev/null <<'EOF'
[Resolve]
FallbackDNS=1.1.1.1 8.8.8.8
EOF
sudo systemctl restart systemd-resolved

Scope

This only affects users with Zero Trust split-horizon DNS / private resource access (the Cloudflare admin pushes a network policy that maps internal hostnames). Plain consumer WARP works fine without these steps.

Until this package gets updated, if anyone needs to use the latest version, can take the version number and updated SHA-256 hash from the official metadata file for noble (the PKGBUILD script builds the package by extracting it from the noble .deb file): https://pkg.cloudflareclient.com/dists/noble/main/binary-amd64/Packages

As of Apr 11 2026, that is 2026.3.846.0 with the SHA-256 checksum d522932b4416fb709ca812ea1db22c3e7cbfe9e9328d97bda9172360e327479f

This isn't working for me. Fails with a daemon/warp-svc.service crash within 5 seconds. Tried to read journalctl, found rust stacktrace.

hi, i'm looking for a way to export the sslkeylogfile for the warp client in order to decrypt and inspect the quic traffic of the connection setup. Any idea how to accomplish this?

could the logout bug be fixed from upstream as per @bzylstra?

The Logout bug is caused by the warp-taskbar service binding to the graphical-session.target. You can fix this by replacing BindTo with PartOf=graphical-session.target in the /usr/lib/systemd/user/warp-taskbar.service file.

Note: Installing this package breaks Logout functionality (tested on KDE). Disabling/Stopping warp-svc won't work because warp-taskbar remains active. As workaround you can install cloudflare-warp-nox-bin.

@solarisfire Please sudo systemctl enable warp-svc.service and try again.