nadoo/glider: a forward proxy that also does DNS and DHCP

What glider actually does that a plain proxy does not

Most proxy tools do one job. glider does several, and the README frames the core idea with a small diagram: a listener accepts traffic, one or more forwarders carry it out, and forwarders can chain into other forwarders. That chain is the part worth understanding. A listener can be an HTTP or SOCKS5 server, a transparent redirect or tproxy socket on Linux, a TCP or UDP tunnel, or a websocket transport. A forwarder can be a remote HTTP, SOCKS5, Shadowsocks, Trojan, VLESS, VMess, SSH or SOCKS4 endpoint. Because both sides are configurable independently, glider works as a protocol converter: clients speak SOCKS5 to it, it speaks Trojan upstream.

The second job is DNS. glider can run a local DNS forwarding server with a cache, force upstream queries over TCP, and attach rules that decide which forwarder a query uses. The third job is ipset management on Linux kernels 2.6.32 and newer: it can add IPs and CIDRs from rule files at startup, and add resolved IPs for domains as the DNS server answers queries. That combination is aimed at people running a Linux gateway or router who want domain based routing without hand-maintaining address lists.

Who this is for: engineers comfortable with command line flags and URL style configuration, running Linux, who want proxy and DNS behaviour in one process. The audience is narrow on purpose. There is no GUI and the feature set assumes you know what a forwarder chain is.

How listeners, forwarders and strategies fit together

The configuration model is URL based. Each -listen value and each -forward value is a URL whose scheme names the protocol, and the README points to config/examples for rule and priority based forwarder choosing. You can pass several -forward flags, and glider picks among them with a strategy: rr for round robin, ha for high availability, lha for latency based high availability, and dh for destination hashing. That choice matters more than it looks. Round robin spreads load with no awareness of whether a forwarder is working; ha and lha depend on the periodic availability check, which by default probes http://www.msftconnecttest.com/connecttest.txt and expects a 200 response, every 30 seconds, with a 10 second timeout, and marks a forwarder disabled after 3 failures.

lha uses the average latency of the latest N checks, where N defaults to 10, and only switches when the new latency beats the old one by more than the tolerance in milliseconds. If you run lha, the check target is part of your routing logic. A check endpoint that is slow for reasons unrelated to your forwarders will move traffic.

The DNS side links into the same routing. The README lists association rules between DNS and forwarder choosing, and between DNS and ipset. So a query for a domain can be answered through a particular forwarder and simultaneously cause the resolved addresses to be written into an ipset, which a firewall rule can then match. That is the mechanism that makes split routing practical without scripts.

Installing glider and running a first listener

The README lists several install paths: prebuilt binaries from the releases page, a Docker image at nadoo/glider, packages for Manjaro, ArchLinux, Homebrew and MacPorts, and installation from source with go install. Pick whichever matches your platform. The source route requires a Go toolchain; the repository's go.mod declares go 1.26.

go install github.com/nadoo/glider@latest

The quickest first run is a single listener with no forwarder, which turns glider into a local proxy server. The README gives this exact example, including the Docker equivalent:

glider -verbose -listen :8443
# docker run --rm -it nadoo/glider -verbose -listen :8443

With that running, point an HTTP or SOCKS5 client at port 8443 on localhost. The README notes that glider serves HTTP and SOCKS5 on the same port, so you do not need two listeners for two client types. The -verbose flag makes the connection log visible, which is what you want on a first run.

To chain through a remote proxy, add one or more -forward flags. The README shows this form:

glider -listen :8443 -forward socks5://serverA:1080 -forward socks5://serverB:1080 -verbose

Two SOCKS5 forwarders with no strategy flag means the default scheduling applies. If you want to see which schemes your build understands, the help text documents a -scheme flag: pass a scheme name for that scheme's help, or all to see every scheme. That is the reliable way to confirm a protocol is compiled in before you write a config file.

For anything beyond a trial, use a config file rather than a long flag list. The help text shows glider -config /etc/glider/glider.conf, and the repository ships a config directory and a systemd directory, so a service unit is the expected deployment shape on Linux.

Where glider stops being the right tool

The DNS server is a forwarder with a cache, not an authoritative nameserver. It has flags for cache size, minimum and maximum TTL, disabling AAAA queries, custom records in domain/ip form, and multiple upstream servers with a switch timeout. There is no mention of zone files, DNSSEC validation or AXFR. If you need those, run a real nameserver and let glider handle only the proxy side.

ipset management is Linux only. The README states the kernel requirement explicitly, version 2.6.32 or newer, and the repository has a feature_linux.go file alongside feature.go, which reflects that split. On macOS or Windows you lose that capability entirely, and the transparent proxy listeners (Redir, Redir6, TProxy) are also Linux specific. TProxy is UDP only according to the protocol table.

The health check default is a real constraint. It probes a Microsoft connectivity endpoint. In a network where that host is blocked, every forwarder will eventually be marked disabled after 3 failures, and your proxy will stop forwarding. The check flag accepts tcp://, http://, https://, file:// with a script that exits 0, or disable. If you are deploying somewhere with restricted egress, plan to change it.

Finally, the release cadence is uneven. The most recent release listed is v0.16.4 from 2024-08-14, after v0.16.3 in 2023-03-13 and v0.16.2 in 2022-05-12. The repository's last push was on 2026-07-15, so work continues on the main branch, but tagged releases lag well behind it. If your policy is to deploy only tagged releases, you are running code that is roughly two years old relative to the branch.

How glider differs from dnsmasq and from single protocol proxies

The closest functional overlap is with dnsmasq, and the comparison is instructive. dnsmasq is a DNS forwarder and DHCP server that can populate ipsets from resolved names; glider does the same DNS and ipset job while also being a proxy with protocol conversion and forwarder chaining. dnsmasq does not proxy TCP traffic at all. If your need is DNS plus DHCP with no proxying, dnsmasq is the smaller dependency and has decades of distribution packaging behind it. If you already need a proxy chain, glider removes the second daemon and the glue between them.

Against single protocol proxies, the difference is the chain. A SOCKS5 server forwards; it does not accept SOCKS5 on one side and emit Trojan on the other, and it has no notion of a forwarder health check with latency based selection. glider's protocol table lists Listen/TCP, Listen/UDP, Forward/TCP and Forward/UDP columns separately, and that matrix is the product. You are buying conversion and chaining, not raw throughput.

The cost of that breadth is configuration surface. The help output is long, with flags for dial timeout, relay timeout, check interval, tolerance, DNS TTL bounds, source interface and rule directories. A single purpose proxy has a fraction of those knobs, which is a real advantage when the person operating it is not the person who set it up.

Maintenance, licensing and what upgrading costs

glider is licensed under GPL-3.0, the LICENSE file at the repository root. That is a copyleft licence. If you modify glider and distribute it, or ship it inside a product, the GPL-3.0 obligations attach to that distribution. Running it as a separate process on your own gateway is a different situation from linking it into your own binary. This is not legal advice; check with your own counsel before embedding it in anything you ship.

On maintenance: the repository is not archived, and its last push was on 2026-07-15. Tagged releases have been infrequent, with v0.16.4 in August 2024 as the most recent listed. The practical consequence is that if you install from source with go install github.com/nadoo/glider@latest you get whatever the module proxy resolves, which may be ahead of the last tag, while package managers and the Docker image may track tags. Decide which of those you are standardising on before you deploy to more than one machine.

The dependency list in go.mod is short and mostly stable Go ecosystem packages, including kcp-go for the KCP transport and an ipset binding. Upgrading is mostly a matter of replacing a static binary, but two things can break silently: a changed default for the health check target or interval, and any change in how rule files are parsed. Keep your rule files and config under version control so a binary swap can be diffed against them.

Editorial conclusion

Adopt glider if you need a single static binary that converts between proxy protocols, chains forwarders with round robin or latency based selection, and ties DNS answers to ipset entries on a Linux router. Do not adopt it if you need a graphical client, a Windows or macOS transparent proxy path, or a DNS server with zone files and DNSSEC; glider's DNS side is a forwarder with a cache and custom records, not an authoritative server. Before rolling it out, verify three things against your own setup: that your kernel is 2.6.32 or newer if you plan to use ipset, that the health check target still answers, since the default check is http://www.msftconnecttest.com/connecttest.txt with expect=200, and that your forwarder URLs are accepted by running glider -scheme all to see the supported scheme list for your build.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. nadoo/glider on GitHub
4. README
5. Releases