Skip to content

Advanced Networking

By default Weaver connects the way your computer does: straight out through your normal network. Advanced networking lets you pick the way out for each Usenet server and each RSS feed. You can split a server across two internet connections, send it through a VPN or proxy, or keep a feed on a tunnel only. Everything lives under Settings → Networking, which has five pages: Overview, Egress, Proxies, Routes, and Bandwidth.

Three building blocks fit together:

  • An egress is a way out of this machine. The System egress uses your operating system’s own routing and always exists. You can add more on Settings → Networking → Egress, each bound to a Network interface (say, a second network card) or a Source address (one IP address on this machine).
  • A proxy is something your traffic hops through on the way out: a VPN tunnel, an SSH server, or a proxy server.
  • A route says which egresses and proxies one server or feed uses. Every server and every feed has its own.

After upgrading to 0.15.0, every existing server and feed starts on the direct route through the System egress, so nothing changes until you edit a route.

A route is made of one to eight legs. Each leg picks an egress, a Weight, and a Path:

  • Direct goes straight out through the leg’s egress.
  • Proxy ladder goes through one or more rungs. Weaver tries rung 1 first and moves down the ladder when a rung fails. Each rung is a single Proxy, a Pool, or a Chain. Tick Allow direct fallback on this egress to let the leg go direct as its last resort.

Every proxy on a leg leaves through that leg’s egress.

Weights split a server’s connections across its legs. They are whole percentages that must add up to 100%. Drag the bar at the top of the editor or type each leg’s Weight. With a 60/40 split and 20 connections, the first leg gets 12 and the second gets 8.

Each leg has a health. A leg that is down, or whose egress health is unknown, takes no traffic. When a leg goes down decides what happens to its share:

  • Redistribute moves its connections to the healthy legs.
  • Hold its share parks those connections until the leg comes back.

RSS feeds work a little differently. A feed tries its healthy legs in order and uses the first one that works. Weights don’t affect feeds.

To try a layout before saving, tick Simulate leg down on a leg. The editor previews where the connections would go. The running route is not changed.

Add proxies on Settings → Networking → Proxies with Add proxy. A proxy keeps its type once saved, so make a new one to switch types.

TypeWhat it needs
WireGuardEndpoint, private key, the peer’s public key, and at least one interface address such as 10.6.0.2/32. Preshared key, DNS servers, MTU, and keepalive are optional. You can upload or paste a WireGuard config file to fill the form.
SOCKS5Host and port, plus an optional username and password.
HTTP CONNECTHost and port, plus an optional username and password.
HTTP/3 CONNECTHost and port, plus an optional username and password.
SSHHost, port, a username, and an Ed25519 private key. Passwords are not supported.

WireGuard runs inside Weaver itself, so you don’t need a separate WireGuard app. How many WireGuard tunnels Weaver can run at once depends on the memory available.

Test checks that a proxy is reachable. A disabled proxy keeps its settings but is skipped when routing.

An SSH proxy carries each connection as a TCP forward, the same thing ssh -W does. The SSH server has to allow TCP forwarding for the account Weaver signs in as. If it doesn’t, connections through the proxy fail with a message that the server refused to forward.

Stock OpenSSH allows forwarding, so a refusal means something on the server turns it off. Look in two places:

  • The key’s line in ~/.ssh/authorized_keys for that account. Delete no-port-forwarding if it’s there. If the line starts with restrict, add port-forwarding after it:

    restrict,port-forwarding ssh-ed25519 AAAA... weaver
  • /etc/ssh/sshd_config and the files in /etc/ssh/sshd_config.d/. Look for AllowTcpForwarding no or DisableForwarding yes. To allow forwarding for the Weaver account only, add this at the end of /etc/ssh/sshd_config, using your account name:

    Match User weaver
    AllowTcpForwarding local
    DisableForwarding no

    local allows the kind of forwarding Weaver uses and nothing else. Then reload the server with sudo systemctl reload ssh (the service is sshd on some distributions).

To check, run this on the Weaver machine with your own news server and SSH server:

ssh -i /path/to/weaver-key -W news.example.com:563 weaver@your-ssh-server

If forwarding works, the command connects and waits; press Ctrl-C to leave. If you see administratively prohibited, forwarding is still off.

A Chain rung goes through two or three proxies in a row, each one tunneling through the one before it. Each row below is a hop’s proxy type, and each column is the type on the hop after it (hop 2 or hop 3):

Hop beforeSOCKS5HTTP CONNECTHTTP/3 CONNECTSSHWireGuard
SOCKS5✅✅❌✅❌
HTTP CONNECT✅✅❌✅❌
HTTP/3 CONNECT✅✅❌✅❌
SSH✅✅❌✅❌
WireGuard✅✅❌✅✅

WireGuard and HTTP/3 travel over UDP, which only a WireGuard hop carries, and only WireGuard can use it. So HTTP/3 can only be a chain’s first proxy, and WireGuard can only be first or follow another WireGuard.

A pool groups 2 to 16 proxies of the same type. Weaver races the members, then prefers the ones that have actually delivered. Create pools under Proxy pools on the Proxies page, and use Test pool to try each member without disturbing live connections.

Settings → Networking → Overview shows totals across the top: egress interfaces and how many are up, proxy profiles and pools, route legs, and open connections with their current speed.

Below that, Connection flow draws your live network. Egress interfaces sit on the left, then route legs, then proxies, then Endpoints, meaning your servers and feeds. The width of each ribbon is the number of open connections. A dashed line is a leg carrying nothing, labelled with what happened to its share. Click a leg to edit that route. Use Download SVG to save the picture.

The Egress interfaces table lists each egress with its Binding / live addresses (what it’s bound to and the addresses it has right now), Health, speed Limit, and Quota usage.

Click Edit egress to change one, or Add egress to make a new one. Test connects to a host you choose through that egress and reports the source address it actually used. That is the quickest way to confirm traffic leaves where you expect. The System egress can’t be renamed, rebound, disabled, or deleted. An egress a route still uses can’t be deleted.

Go to Settings → Networking → Routes. The Consumer routes table lists every server and feed with its route and live state. Click Edit route. A server’s or feed’s own editor in Settings shows its route too, with an Edit in Networking link.

The route editor only offers choices the route can actually use:

  • A disabled egress isn’t offered for a new leg.
  • A proxy already used on a leg’s ladder isn’t offered again on that ladder, counting pool members and chain hops.
  • A feed’s route only lists proxies and pools whose proxies all have DNS servers set, because a feed looks up names through its proxies. In the proxy editor, DNS servers are a WireGuard setting.

Weaver won’t save a route that:

  • has more than eight legs, or weights that don’t add up to 100%;
  • has a ladder rung with nothing chosen, or a chain with fewer than two different proxies;
  • uses a disabled egress, or repeats a proxy on one leg’s ladder;
  • uses more than eight proxies.

When you add a server under Settings → Providers or a feed under Settings → RSS, the Network route section has a Kill switch toggle. Turn it on and the record is saved switched off, with nothing allowed out: no proxy and no direct fallback. It can’t reach the network at all. Then set its route under Networking and switch it on.

The kill switch is a starting state, not a lasting guarantee. If a later route edit adds a direct leg or ticks Allow direct fallback on this egress, Weaver follows the route as saved. To keep a server VPN-only:

  • Give every leg a Proxy ladder path, never Direct.
  • Leave Allow direct fallback on this egress unticked on every leg.
  • Check the route again after any change.

A setting that enforces “never go direct” is planned for a later release.

Any egress, the System egress included, can have a download quota. This replaces the old ISP bandwidth cap. It’s useful for a metered connection, like a mobile hotspot or a capped second line.

Open the egress’s editor and turn on Enforce a download quota. Pick a Quota window of One block, Daily, Weekly, or Monthly, and set the Allowance. Daily, weekly, and monthly windows also take a Reset at time, weekly ones a Reset day, and monthly ones a Reset day of month. These are the same choices a server’s quota uses. A one-block allowance never resets on its own.

When the allowance runs out:

  1. The egress refuses further downloads and every leg on it goes down with Quota reached.
  2. That leg’s share moves to the route’s other legs, following its When a leg goes down choice.
  3. If a job has no leg left with room, it waits as blocked. The downloads list shows Egress quota and Until the reset time, and a notice reads Download quota reached on the egress’s name.

Raise the allowance and the block lifts straight away. Reset usage in the egress’s editor starts the current window’s count over without clearing the egress’s lifetime total.

Usage shows in the egress editor, the egress table’s Quota column, the Download quotas table on Settings → Networking → Bandwidth, the Download quotas section of Monitoring, and the downloads list when a job is blocked.

Egress quotas and server quotas both apply. A server quota limits what one provider account can use. An egress quota limits what one connection can carry across every server routed over it. When both hold work back, the egress quota is the one shown.

If you had an ISP bandwidth cap turned on before upgrading, it becomes the System egress’s download quota. The bytes already counted in its current window carry over, so the quota picks up where the cap left off. A cap that was turned off is dropped.

Each egress can also carry its own Download limit in MiB/s, set in its editor or under Egress limits on the Bandwidth page. The global and per-server limits still apply on top of it. Schedules can set per-egress speed limits and turn quota metering on or off for one egress or every egress. See Scheduling.

  • Windows can’t bind to an interface by name, so the Network interface choice isn’t offered. Use Source address instead, and Windows sends through the adapter that owns that address. That adapter needs its own default gateway, because Windows picks the way out by source address alone.
  • Linux and macOS: a source address alone may not change the way out. Bind the interface instead, or add a source policy rule (Linux) or a scoped route (macOS).
  • DNS doesn’t follow the egress. Weaver looks up server and proxy names with your system’s resolver, and those lookups may use your default route. If DNS must go through a tunnel, point the system at a resolver that’s routed through it.
  • Docker: with the default bridge network, Weaver only sees the container’s own interface, and the Networking page shows a notice saying so. To pick between real host links, use host networking or attach several container networks.
  • Docker and interface binding: binding to an interface on Linux may need the NET_RAW capability. The Weaver image drops NET_RAW at startup, even when PUID is 0, unless you set WEAVER_RETAIN_NET_RAW=true. Grant only that capability. NET_ADMIN isn’t needed.

Proxies, WireGuard, chains, pools, and the kill switch work the same on every platform.

/metrics exports the network state for Prometheus:

  • weaver_network_leg_* and weaver_network_egress_* for leg state, connections, throughput, and egress health.
  • weaver_egress_download_quota_*{egress_id} for each egress’s quota, and weaver_download_quota_block_window_end_seconds for when a quota block lifts.

The sample alert rules add WeaverDownloadsGatedByEgressQuota, for downloads held by an egress quota for 15 minutes, and WeaverEgressQuotaNearlyExhausted, for an egress past 90% of its quota. They replace the old ISP cap gauges and alerts.