Share a Windows proxy with one trusted LAN device using an authenticated sing-box listener bound to the host's private address. This guide uses Windows 11 x64, sing-box v1.14.2, and Firefox on another Windows 11 device. These browser-proxy checks are not completed author tests.

Key Takeaways

Bind one private IPv4 address and allow one client's source address.

A username and password restrict proxy use but do not encrypt the LAN connection.

Configure the client browser explicitly; other applications retain their own network behavior.

Stop the listener and remove the client setting when the sharing session ends.

What does it mean to share a Windows proxy?

The client browser asks sing-box to open connections; Windows is not acting as an ICS gateway or transparent router. Read the primer on operating your own network services before deciding who owns the listener, password, updates, and shutdown.

If your task requires system-wide capture, compare TUN capture with explicit system-proxy behavior instead. A proxy setting cannot promise every application's traffic will follow it. The hotspot VPN coverage checks also explain why sharing connectivity does not automatically share a VPN route.

The baseline outbound is direct, using the host's existing route; authenticated sharing need not change the public exit. Integrate an already authorized upstream separately only after verifying protocol, authentication, routing, and failure behavior. Remote subscription configuration is outside this procedure.

What do you need for Windows LAN proxy sharing?

Use two devices you control on a private, trusted LAN. Reserve host 192.168.50.10, client 192.168.50.20, and TCP 2080; substitute your actual addresses everywhere. Prefer DHCP reservations so the client restriction does not silently refer to a different device after a lease change.

Record the host's profile, addresses, firewall rules, and both browsers' settings, including the client's original managed PAC URL where applicable. Keep these privately; obtain administrator configuration rather than overriding workplace browser or firewall policy.

Use only a network that legitimately merits the Private profile. Do not reclassify a public hotspot to make an allow rule work. If Wi-Fi client isolation prevents peer connections, stop or choose an authorized private network; do not disable a venue's controls.

Use the device troubleshooting baseline to separate an existing network failure from a proxy configuration problem.

Step 1: Install the official package and protect its configuration

Download and extract the official v1.14.2 Windows amd64 executable to C:\LANProxy. The owner maintains Windows and packages. Start this manual session without automatic startup.［1］

Create config.json in that directory under your normal account. Restrict its file permissions so only that account, SYSTEM, and Administrators can read it; do not place the password in a shared folder, browser bookmark, screenshot, or repository. Administrator access is needed to add the firewall rule, but the high-port proxy itself runs as the normal user.

In the following example, replace the password with a unique password-manager-generated value and replace both IP addresses used by the guide. Keep the host address consistent between configuration and firewall. The mixed listener accepts supported SOCKS/HTTP protocols; a nonempty users list is necessary because an empty list permits unauthenticated use.［2］

{
  "log": {"level": "info", "timestamp": true},
  "inbounds": [{
    "type": "mixed", "tag": "trusted-lan",
    "listen": "192.168.50.10", "listen_port": 2080,
    "users": [{"username": "lan-reader", "password": "REPLACE_WITH_UNIQUE_PASSWORD"}],
    "set_system_proxy": false
  }],
  "outbounds": [{"type": "direct", "tag": "direct"}],
  "route": {"final": "direct"}
}

set_system_proxy: false preserves the host's system proxy. This direct-only configuration adds no TUN, routing changes, transparent capture, or UDP sharing. A different outbound requires new verification.

Step 2: Limit access to the trusted client's address

First inspect Windows Firewall's active profile and inbound policy. Leave the firewall enabled and unsolicited inbound traffic blocked. Review any pre-existing rule for sing-box or port 2080, including installer-created rules: a broad allow can defeat the intended restriction even when a narrower rule exists.［3］

Use an elevated PowerShell window only to create this owned rule:

New-NetFirewallRule -Name 'SingBox-LAN-Lab' -DisplayName 'Sing-box one-client LAN lab' -Direction Inbound -Action Allow -Protocol TCP -LocalAddress 192.168.50.10 -LocalPort 2080 -RemoteAddress 192.168.50.20 -Program 'C:\LANProxy\sing-box.exe' -Profile Private

Decline any subsequent prompt to allow the application on all public networks. Do not forward this port on your router. The source-address restriction is useful access control, but the password is still required; IP addresses alone do not establish device identity against every attacker on the same LAN.

The example has no IPv6 listener. Do not add ::, 0.0.0.0, a subnet-wide source, or an unrestricted second rule for convenience. If the interface address changes, stop and update both configuration and rule after identifying the new trusted network.

Step 3: Start sing-box and configure one Firefox browser

From normal PowerShell, run the following sequence. A successful configuration check verifies parsing, not the firewall, browser path, or password rejection.

cd C:\LANProxy
.\sing-box.exe version
.\sing-box.exe check -c .\config.json
.\sing-box.exe run -c .\config.json

Leave the foreground process visible. In a separate PowerShell window, inspect the address and port:

Get-NetConnectionProfile
Get-NetIPAddress -AddressFamily IPv4
Get-NetTCPConnection -State Listen -LocalPort 2080 | Select-Object LocalAddress,LocalPort,OwningProcess
Get-NetFirewallRule -Name 'SingBox-LAN-Lab' | Get-NetFirewallAddressFilter

The listener must be the intended private IPv4, not a wildcard or unexpected IPv6 address. Match its PID to this session's sing-box process. If a different process owns the port, choose a free high port and update every reference; do not terminate unrelated processes.

On the client, open Firefox Settings → General → Network Settings → Settings → Manual proxy configuration. Set HTTP Proxy to 192.168.50.10, port 2080, and enable the option to also use it for HTTPS. Leave SOCKS and automatic configuration unused. On versions with separate HTTPS fields, enter the same host and port there. Mozilla documents these connection choices.［4］

Save, open a new private browsing session, and visit an authorized HTTPS site. Enter lan-reader and the generated password when prompted. Do not accept a new certificate authority or certificate warning: this relay does not require TLS interception. “HTTPS proxy” here describes HTTPS requests using CONNECT through the HTTP proxy; it does not mean the browser-to-proxy connection is encrypted.

How do you verify sing-box proxy authentication and coverage?

Use a new session or restart Firefox between credential tests, so cached credentials and established connections do not hide failures. Never put a password directly in a command-line URL. Keep any temporary logs private and discard credentials after the session.

Reader check	Expected result	What it establishes
Correct credentials on the allowed client	Intended HTTPS request loads; proxy activity corresponds	That browser request used the available proxy path
Cancel authentication or use a wrong password	Request fails or authentication repeats	Unauthenticated forwarding is not available for that request
Request from another authorized lab device	Connection blocked before useful proxy traffic	The source-address rule applies; correct credentials alone are insufficient
Stop sing-box while Firefox still points to it	New non-exempt HTTPS request fails	The browser is depending on the explicit listener
Use a separate app with no proxy setting	Its pre-existing route remains	Browser configuration does not establish application-wide capture

If no second source device is available, mark the firewall-rejection runtime check untested; inspecting the rule is not equivalent. Restore correct credentials and a new session after each negative test. A cached page does not count as a new request.

You may compare the browser's visible exit for this request before and after configuration. With the direct upstream, the exit may be identical. That equality neither proves nor disproves proxy use; use the correlated listener activity and the stop-listener failure check. An already configured VPN on the host can also affect egress, and this guide does not change it.

Firefox's proxy bypass list, local destinations, DNS settings, and existing encrypted DNS policy need separate attention. Do not infer DNS, UDP, IPv6, or all-app coverage from one successful HTTPS page. Start with a non-exempt destination and record the browser settings used.

How do you recover from sleep or remove the sharing session?

After sleep, reboot, or a network change, recheck the host address, Private profile, client address, listener ownership, and authentication. This manual process does not promise restart after reboot. If Windows changes to a Public profile, the Private-only rule should no longer allow sharing; do not widen it to restore service on an untrusted network.

For connection failures, distinguish Windows proxy fields and their scope from the browser's independent setting. If the LAN itself comes from Windows Mobile Hotspot, resolve hotspot connectivity problems before debugging authentication. These are prerequisites, not an instruction to enable ICS here.

To end the session, press Ctrl+C in this process's foreground window, confirm its listener is gone, and repeat a new proxied request to see it fail. Restore the recorded Firefox connection setting and clear the temporary proxy credentials. In elevated PowerShell, remove only SingBox-LAN-Lab with Remove-NetFirewallRule -Name 'SingBox-LAN-Lab'; inspect the rule list afterward.

Remove the private configuration and session logs when no longer needed. Keep only a sanitized template without live credentials. For future updates, preserve the previous trusted package and private configuration, validate the replacement before reopening the rule, and repeat authentication, source rejection, and shutdown checks. If Android should be the sharing host instead, follow the Every Proxy hotspot procedure rather than adapting Windows firewall commands.

Summary

Keep a one-client firewall policy and explicit proxy authentication together.
Treat the browser's successful request as evidence of that request only.
Recheck address and profile changes after sleep or reboot.
Stop the listener, restore client settings, and remove the owned rule when finished.

FAQ

Does a mixed listener encrypt my LAN traffic?

The mixed listener does not itself create an encrypted link to the proxy. Destination HTTPS protects its own payload, but HTTP proxy authentication is not LAN encryption.

Why is the public IP unchanged?

The direct outbound often uses the same internet exit the client already had. Use authentication and listener shutdown checks to establish the proxy dependency instead.

Can another app use the proxy automatically?

Only an application that honors the configured proxy will use it. A Firefox-only setting does not configure another browser, a game, or the Windows update service.

Should I allow the whole private subnet?

This procedure authorizes one client's current source address. Expanding to a subnet changes the access boundary and needs a separate configuration decision and verification.

What if Firefox never asks for a password?

Check cached credentials, existing connections, the users list, and whether the request bypasses the proxy. A fresh session and wrong-password test give stronger evidence than the absence of a prompt.

Does this procedure share an existing VPN?

It does not establish that outcome. The proxy uses the host's available upstream route, whose interaction with any existing VPN must be verified separately without assuming all traffic is captured.

Can I leave the listener running after the client disconnects?

The process can remain available while running, but this lab's default is session-based sharing. Stop it and remove temporary access when the trusted client no longer needs it.

Disclaimer: Use only devices and networks you are authorized to administer. This source-based guide has not been fully tested end to end on a Windows LAN.

Sources:

Sources checked 11 October 2026.

Related Articles:

Share a Windows Proxy over LAN with One Trusted Device