# lan-proxy-gateway turns a Mac into a proxy for the whole living room

> Tght1211/lan-proxy-gateway shares an existing Clash, Mihomo or sing-box endpoint with PS5, Switch, Apple TV and phone clients over a Wi-Fi hotspot, a manual gateway or an HTTP and PAC listener. It ships a SwiftUI app, a CLI and a Go core, and it is explicit that it supplies no proxy nodes of its own.

**Tght1211/lan-proxy-gateway** — 无需软路由，让你的Wi-Fi科学上网，网络加速ps5、switch、手机等可连Wi-Fi的设备。仅需一台macmini或者mac电脑，暂不支持windows

- Repository: https://github.com/Tght1211/lan-proxy-gateway
- Stars: 533 · Forks: 57
- Language: Go
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/tght1211-lan-proxy-gateway

## Sharing one upstream with devices that have no proxy client

The problem this project addresses is ordinary in a household: the Mac on the desk runs a proxy client, but a PS5, a Switch, an Apple TV and a phone cannot easily run one, and the router has no idea the proxy exists. lan-proxy-gateway sits in the middle on the wired Mac or on a Mac or Linux box in the same subnet, and forwards those devices' traffic through the proxy you already have.

Importantly, the project does not distribute nodes or subscriptions. The documentation states plainly that you need an existing Clash, Mihomo, sing-box or HTTP and SOCKS5 endpoint, and that availability depends on that upstream and on the target sites. What the gateway adds is the plumbing: three ways for a device to reach it, per-device and per-domain rules, a traffic ledger, and an interface for reading all of it.

The three access methods have different prerequisites. The Wi-Fi hotspot route needs a Mac on a wired connection with Internet Sharing already enabled in the system, after which the app takes over the hotspot and the client keeps automatic IP, gateway and DNS with no proxy software at all. The manual gateway route works with a Mac or Linux machine on the same LAN, where the client gets a static IP on the real subnet and points its gateway and DNS at that machine. The HTTP and PAC route turns on the app's LAN HTTP proxy, and clients either fill in a server and port or point at the listener's `proxy.pac` URL, again with no gateway or DNS change.

The target audience is therefore someone with a heterogeneous device mix, not a company deploying a filtered egress for a fleet.

## Ordered splitting: device policy first, then domain and IP rules

The Go core is described as a device policy and ordered splitting engine. The project's own architecture diagram draws a single path: a LAN device reaches an access layer covering the hotspot, the manual gateway, and the HTTP and PAC listener; that access layer feeds the core, where device policy and ordered splitting decide the outcome; and the core resolves each flow into one of three results, a local direct connection, the existing HTTP or SOCKS5 upstream, or a refusal. The SwiftUI app, the CLI and the exported Agent skill all point into that same core, which is what makes the three front ends consistent with one another.

Access lands in the core, and the core resolves the flow into one of three outcomes: local direct connection, the existing upstream, or refusal. The SwiftUI app, the CLI and the exported Agent skill are three front ends over the same core and the same configuration, so a change made in the app is visible to the CLI, and the configuration file `gateway.example.yaml` is the source of truth both read.

Splitting rules work in a fixed order. Device policy takes priority, then a rule can match an exact domain, a domain suffix, or an IP-CIDR block, and the action is proxy, direct or reject. The order matters because it decides which of two overlapping matches wins, and the interface in v4.5.2 filters configuration rules by all, proxy, direct and reject, with the view no longer split by asset perspective.

Routing is a decision, not a proxy chain. The core supports a single HTTP or SOCKS5 upstream, and the documentation is explicit that several exit cards in the interface do not mean several configured proxy nodes.

## Learning which destinations need the proxy, and when to stop learning

The auto-learning feature is the part of the design that most deserves a skeptical read. The stated behaviour: an unmatched destination is tried over a direct connection first, and only after the direct attempt fails, or after a first-response timeout triggers a retry condition, is the proxy tried. Evidence accumulates only when the proxy actually returns a response, and once a threshold is reached the entry is either saved automatically or left waiting for confirmation. Explicit rules and the setting that forbids direct connections take priority over anything the learner has recorded.

The consequence is that every new destination you visit pays for a direct attempt first. For a site blocked or unreachable without a proxy, that means a visible stall before the traffic is routed correctly, and the delay depends on how long the direct attempt takes to fail. The documentation does not state the threshold value or the exact timeout, so the trade-off cannot be tuned from what is written down.

Management is also deliberately layered. Learned entries are grouped as pending confirmation, saved, and learning paused, then filtered by service, route and scope, with 50 rows per page and identifiers for legacy direct rules preserved. One clarification is worth keeping in mind: pausing learning does not mean refusing access.

For a household this mostly works, because the set of destinations is small and stable. For a shared office network, a learner that retries direct first will produce a burst of failed connections every time a new service appears.

## Getting it running: DMG, CLI install, then pick an access mode

On macOS the documented path is the DMG from the releases page, dragged into Applications, then pointing the app at your existing proxy by entering its real type, address and port in the network overview. The documentation warns against a specific mistake here: do not use the shared HTTP listening port as the upstream, since that is the port the gateway itself exposes to the LAN rather than the proxy you already run.

For macOS and Linux there is a CLI install:

```bash
curl -fsSL https://raw.githubusercontent.com/Tght1211/lan-proxy-gateway/main/install.sh | bash
sudo gateway install
```

The install script is fetched from the main branch and the `gateway` binary is then installed, with the sudo step implying system-level changes to firewall and service setup. The Makefile shows where the binary lands, `/usr/local/bin/$(BINARY)`, and the `uninstall` target removes it again.

Pick the access mode before you expect traffic to flow, and read the warning that comes with it: switching between hotspot and manual gateway mode requires a restart of the core, and a restart interrupts existing connections. Operations touching the firewall or system services may prompt for administrator authorisation.

Once running, the app's pages map cleanly onto the feature set: network overview for topology and exits, device access for per-device usage, traffic records for connections and learning entries, configuration rules for the splitting policy, and settings for access mode, CLI, agent and runtime options. The interface remembers the filters and scroll position of pages you have visited.

## One upstream, no Windows, no IPv6, and no arbitrary UDP

The documentation has a limits section that is unusually direct, and it should be read before install rather than after. The core supports one HTTP or SOCKS5 upstream. Windows, OpenWrt and IPv6 transparent proxying are not provided. The HTTP listener does not carry arbitrary UDP, and proxy mode blocks QUIC on UDP port 443 to push clients back to TCP, while other UDP still goes direct.

That QUIC decision has a cost. Applications that prefer QUIC will be forced back to TCP through the proxy path, which usually works but is not the same path they chose. The documentation says game NAT and online play results have to be measured, which is a good sign of honesty and a bad sign for predictability: a console title whose matchmaking or voice chat depends on UDP behaviour outside the documented path is exactly where this design is weakest.

The traffic accounting is narrower than a normal proxy bill. Only forwarded bytes that pass through the gateway are counted, excluding traffic that bypasses it, other applications' proxy traffic on the same Mac, and protocol overhead. The numbers are not what your provider bills, and older records without an exit classification cannot be back-converted into proxy usage.

Data retention is also limited. Daily summaries are persisted, but individual connection records live only in memory for 72 hours and at most 2000 entries. A response arriving is not a business success, and HTTPS contents are never decrypted.

## Driving the gateway from an AI agent over a local management API

The newest feature is an external agent interface. In the app's CLI and agent settings you export a Skill ZIP and hand the installation instructions to an agent that supports skills and can run commands on the gateway computer, with Codex named as an example. The whole `lan-proxy-gateway/` directory has to be installed, and after a software upgrade you re-export and update the installed copy, so the skill is a snapshot of the CLI surface rather than a live link to it.

The design choice worth noting is what the skill does not do. It ships read-only summary and categorised paging tools, so an agent can look at a few thousand rules in slices instead of pulling the entire configuration into a conversation window. The management API stays on the local machine with its own separate authentication, and the agent is expected to diagnose first, modify only what the user authorised, and not restart anything or open remote management on its own.

For building the core and the app from source, the Makefile exposes the usual targets:

```bash
make build
make test
make build-app
make dmg VERSION=v4.5.2
make skill VERSION=v4.5.2
```

The Go module requires Go 1.25.0 and pulls in cobra for the command line, the miekg/dns resolver, golang.org/x/net, yaml.v3 for configuration, and the fatih/color and spf13/pflag pair. Packaging a universal macOS app needs a full Xcode or a GitHub macOS runner; with only the Command Line Tools present, the SwiftUI shell is built for the local architecture alone.

## The alternative: configure the client, or put the proxy in the router

There are two honest alternatives, and they fail in different ways. The first is to configure each device to use the proxy directly, which some consoles and smart TVs simply do not offer, and which on a phone means an always-on VPN profile or a per-app client. The second is to put proxying in the router itself, either with an OpenWrt build or a dedicated gateway device. That approach avoids the single upstream limit and keeps the LAN gateway out of the picture entirely, but it demands hardware and router firmware support, and it is the route this project explicitly does not take.

The difference in approach is the placement of the trust boundary. lan-proxy-gateway keeps the upstream on your own machine, keeps the management API local, and lets a single device act as the exit for a household. It trades the router's always-available throughput for a Mac that has to be awake, with a static IP assigned to it, for the manual gateway mode to work at all.

Note also the effect on the source machine itself: the app preserves the Mac's own existing system proxy and DNS settings, and the core distinguishes local direct traffic from forwarded traffic, including a separate direct probe introduced in v4.5.2 that checks Baidu independently rather than borrowing a proxied result. That probe needs a core restart after the upgrade before it takes effect.

## Release pace and licence: frequent patches, permissive terms

The repository is not archived, and the last push was on 2026-10-08, with v4.5.4 published the same day. Before that came v4.5.3 on 2026-10-05 and v4.5.2 on 2026-10-03. Release notes are kept per version under `docs/releases/`, and the changelog sits at the top level of the repository. The cadence is fast, which is good for a network tool and a consideration for stability, since a core restart is required after switching access modes and after upgrading to a version that changes probing behaviour.

The licence is MIT, and the project publishes a separate English README, per-platform documents under `docs/`, an example configuration file and an exported skill directory. The application is a SwiftUI front end over a Go core, and the CLI shares that core and configuration rather than wrapping a separate implementation, so behaviour does not drift between interfaces.

For a tool that touches firewall rules, system services and DNS on a machine that is also your daily driver, that shared core is the reassuring part of the design.

## Conclusion

Adopt lan-proxy-gateway if you already run a Clash, Mihomo or sing-box endpoint and want consoles and TVs on your Wi-Fi to use it without installing client software on each device. Skip it if you need Windows, OpenWrt, IPv6 transparent proxying, more than one upstream, or a game whose traffic depends on UDP and QUIC behaviour this project says it does not carry. Before you commit, confirm the upstream type and port you point it at, read the traffic accounting rules, and test one device of each access mode on a network you can recover from, because switching modes restarts the core and interrupts live connections.

## FAQ

### Does lan-proxy-gateway provide proxy nodes or subscriptions?

No. The project states that it supplies no proxy nodes or subscriptions, and that you need an existing Clash, Mihomo, sing-box or HTTP and SOCKS5 endpoint. Availability of the service depends on that upstream and on the target sites.

### How do I install lan-proxy-gateway on macOS or Linux?

On macOS you download the DMG from the releases page and drag the App into Applications, then enter the type, address and port of your existing proxy. The CLI route on macOS and Linux runs the install.sh script and then `sudo gateway install`, which places the `gateway` binary in /usr/local/bin.

### Which devices can use the gateway and how do they connect?

Three access methods are supported: a Mac Wi-Fi hotspot that a wired Mac takes over, a manual gateway where the client uses a static IP pointing at the Mac or Linux machine, and an HTTP or PAC listener where the client enters a server and port or uses the `proxy.pac` URL. The documented targets include PS5, Switch, Apple TV and phones.

### Can lan-proxy-gateway use more than one proxy upstream?

No. The core supports a single HTTP or SOCKS5 upstream, and the documentation clarifies that several exit cards in the interface do not mean several configured proxy nodes. Multiple exit cards can instead reflect different routing results rather than different upstreams.

### Does lan-proxy-gateway work on Windows and does it carry game traffic?

Windows and OpenWrt are not supported, and IPv6 transparent proxying is not provided. The HTTP listener does not carry arbitrary UDP, proxy mode blocks QUIC on UDP port 443 to push clients back to TCP, and the documentation says game NAT and online play results need to be measured.

### How accurate are the traffic statistics?

They count only forwarded bytes that pass through the gateway, excluding bypassed traffic, other applications' proxy traffic on the same Mac, and protocol overhead, so they do not match a provider bill. Daily summaries are persisted, while individual connection records are kept in memory for 72 hours and at most 2000 entries, and HTTPS contents are not decrypted.

## Sources

- [Issues](https://github.com/Tght1211/lan-proxy-gateway/issues)
- [License: MIT](https://github.com/Tght1211/lan-proxy-gateway/blob/main/LICENSE)
- [README](https://github.com/Tght1211/lan-proxy-gateway/blob/main/README.md)
- [Releases](https://github.com/Tght1211/lan-proxy-gateway/releases)
- [Tght1211/lan-proxy-gateway on GitHub](https://github.com/Tght1211/lan-proxy-gateway)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tght1211-lan-proxy-gateway