Most guides that promise to teach you how to block apps via proxy settings stop at “open Settings, tick a box.” That works until the first application ignores the box – and many do. Native desktop clients, game launchers, and telemetry agents frequently open raw sockets that never consult your proxy configuration at all.
If you administer a fleet of machines, run automation, or manage a network of browser profiles, you need blocking that holds under real traffic. This guide covers the enforcement points that actually decide whether an app is stopped, working PAC and proxy-ACL examples, and the failure modes that quietly let traffic through.
To block apps via proxy settings, you route an application’s traffic through a proxy you control, then deny the destinations you don’t want it to reach – either by pointing matching requests at a non-routable (“dead”) proxy in a PAC file, by adding a deny rule on an explicit proxy such as Squid, or by forcing all egress through the proxy so anything unmatched is dropped.
Where a Block Actually Happens
A proxy block can be enforced at four different points, and choosing the wrong one is why most attempts leak. The point you pick determines granularity, resistance to user override, and how HTTPS is handled.
- Client PAC logic – the browser or OS evaluates a script and decides per request whether to proxy, connect directly, or fail.
- Explicit proxy ACLs – the proxy server accepts the connection and returns a denial for blocked destinations.
- Forced egress – a firewall permits outbound traffic only to the proxy, so any app that skips the proxy is dropped by default.
- Per-application proxifiers – a client-side agent intercepts a named process and applies a block or route rule to that process alone.
The rest of this article works through the three methods built on these points, then the trade-offs between them.
Method 1 – PAC Files and the Dead-Proxy Trick
A Proxy Auto-Config file is a JavaScript function, FindProxyForURL(url, host), that the client calls for every request and that returns where the request should go. It’s the most portable way to block apps via proxy settings on managed browsers, because one file governs every endpoint that loads it.
The blocking mechanism is subtle. You don’t “deny” inside a PAC file – you route the blocked host to a proxy that cannot answer, and you deliberately omit a working fallback:
function FindProxyForURL(url, host) {
// Send unwanted destinations to a proxy that does not exist.
if (shExpMatch(host, “*.telemetry-vendor.com”) ||
shExpMatch(host, “ads.*”)) {
return “PROXY 127.0.0.1:1”; // no route, no DIRECT -> request fails
}
// Everything else uses the real gateway.
return “PROXY gateway.internal:3128”;
}
The critical detail is the missing DIRECT. The moment you write “PROXY 127.0.0.1:1; DIRECT”, the client tries the dead proxy, times out, and then connects straight to the destination anyway. Your block fails open. This single mistake accounts for a large share of “the PAC file doesn’t work” tickets.
Match by Host, Protocol, or Subnet
shExpMatch(host, “*.example.com”) covers domain families. isInNet(host, “10.0.0.0”, “255.255.248.0”) blocks or exempts an entire subnet. You can even branch on protocol by testing url against “https:*” versus “http:*”, which is useful when an app talks plain HTTP for updates.
The HTTPS Limitation You Can’t Ignore
For HTTPS requests, the client only exposes the hostname to the proxy layer, not the full path – the path and query of https:// URLs are stripped before the function runs. That means proxy-settings blocking is reliable at host granularity but cannot, on its own, block one page of an HTTPS site while allowing another. Path-level control requires TLS interception, which certificate-pinned apps will reject outright.
PAC files are also cached by the client, often keyed by domain, so an updated rule may not take effect until the cache expires. Plan for a propagation delay rather than expecting instant enforcement.
Method 2 – Deny Rules on an Explicit Proxy
PAC logic lives on the client, so a determined user can edit or remove it. When you need a block the endpoint cannot override, move enforcement onto the proxy itself. With Squid, the pattern is an access control list plus an explicit deny:
acl blocked_apps dstdomain .telemetry-vendor.com .metrics.example.net
acl work_hours time MTWHF 09:00-18:00
http_access deny blocked_apps work_hours
http_access allow all
Because the decision is made server-side, the client’s own proxy settings can’t route around it – the connection is refused at the point where it’s tunneled. You also gain time-based and source-based conditions, and every denied request is logged, which turns “is this app phoning home?” from a guess into a query.
The caveat mirrors Method 1: for HTTPS the proxy sees the CONNECT host:port request, so you filter on the hostname. Full-URL filtering means decrypting traffic, and decryption breaks pinned clients.
Method 3 – Force Every App Through One Gateway
Methods 1 and 2 assume the application is proxy-aware. Plenty aren’t. To bring those under control, invert the model: set your system proxy to the controlled gateway, then use the host firewall to permit outbound traffic only to that proxy’s IP and port. Anything that tries to connect directly is dropped.
Now a non-cooperative app has two options – use the proxy (where your ACLs apply) or be silently blocked. On Windows this pairs a system proxy with an outbound Windows Defender Firewall rule; on Linux, iptables/nftables restricting egress to the proxy address does the same job.
For per-process precision without touching the firewall, a proxifier such as Proxifier intercepts named executables and applies a rule to each – including an explicit Block action. That’s the cleanest way to stop one specific application while leaving the rest of the machine untouched, and it works regardless of whether the app respects the OS proxy setting.
The same per-profile logic underpins anti-detect browser setups: each profile is bound to its own proxy, and a profile whose destinations are denied at that proxy is effectively contained. The proxys.io Proxy Control extension applies this at the browser level, letting you assign a specific IP per profile and keep a whitelist of permitted sites.
Choosing a Method
The right approach depends on how much control you have over the endpoint and how hard the app tries to avoid supervision.
| Method | Enforcement point | Granularity | HTTPS handling | Override resistance | Setup effort |
| PAC dead-proxy | Client (browser/OS) | Host, protocol, subnet | Host-level only | Low – user can edit the file | Low |
| Explicit proxy ACL (Squid) | Proxy server | Host, port, time, source | Host-level; path needs decryption | High | Medium |
| System proxy + firewall | Client + network | All outbound traffic | Host-level | High | Medium–High |
| Per-app proxifier | Client process | Single application | Per-process | Medium | Low–Medium |
A practical rule: use PAC for fast, low-friction control on browsers you manage; move to explicit-proxy ACLs when the block must survive a curious user; add forced egress or a proxifier when the target app ignores standard proxy settings entirely.
Why Blocks Leak – and How to Close the Gap
A block that “mostly works” is a block that doesn’t work. Most leaks trace back to a handful of causes, and each has a concrete fix.
| Symptom | Root cause | Fix |
| App still connects after a PAC block | DIRECT left in the return string, or the app ignores PAC | Remove the fallback; enforce with firewall or a proxifier |
| HTTPS destination not blocked by a path rule | Proxy sees only the CONNECT hostname | Block at host level, or enable inspection (pinned apps will fail) |
| Real IP appears despite the proxy | WebRTC, native sockets, or DNS resolving outside the proxy | Force all egress through the proxy; disable WebRTC; use proxy-side DNS |
| Block works, then intermittently fails | Shared or blacklisted proxy IP, unstable link, cached PAC | Use a dedicated IP; shorten PAC cache lifetime |
| A few apps ignore every rule | Application is not proxy-aware | Route it explicitly with a proxifier or lock down egress at the firewall |
The DNS and WebRTC entries deserve emphasis. An application can honor your proxy for HTTP while resolving names through a system resolver that talks directly to the internet, revealing intent and sometimes the real address. Routing DNS through the proxy – or blocking outbound port 53 except to approved resolvers – closes that path.
The Part Providers Rarely Mention: IP Quality
Every method above assumes the proxy behind your rules is stable and clean. In practice, the weakest link is usually the IP, not the config.
Shared addresses cause the “works then fails” symptom directly: when several users route through the same IP, the proxy’s behavior becomes unpredictable, and a reputation hit from one user degrades everyone’s sessions. Intermittent disconnects then look like a broken ruleset when the ruleset is fine.
This is where a dedicated IP earns its cost. proxys.io Individual IPv4 addresses are assigned to a single user from around $1.40 per IP per month, with HTTP, HTTPS, and SOCKS support, so the endpoint your ACLs point at stays consistent rather than shifting under load. A stable proxy is the difference between a block you can trust and one you have to keep re-testing.
Benchmark before you commit: point one test application at the proxy, apply a deny rule, and confirm both that blocked hosts fail and that allowed traffic stays fast under sustained requests. A method that passes on a single request often collapses under a few hundred.
Going Deeper
Proxy-level app control sits alongside two adjacent topics worth studying next: forcing an entire operating system through a single upstream proxy, and assigning a distinct IP to each browser profile for isolated, per-context routing. The setup walkthrough for the Proxy Control extension is a good starting point for the per-profile approach, since it shows the whitelist and per-IP assignment in practice.
Frequently Asked Questions
Can you block apps via proxy settings without admin rights?
Partially. A PAC file applied to a browser you already control needs no elevated rights, but it only governs proxy-aware traffic. Blocking non-cooperative applications requires firewall or proxifier changes, which do need administrative privileges on the endpoint.
Why does an app still reach the internet after I block it in proxy settings?
Almost always one of two reasons: the application doesn’t consult the system proxy and opens direct sockets, or your PAC file left a DIRECT fallback that connects anyway. Force egress through the proxy or remove the fallback to close it.
Does blocking an app via proxy also stop its HTTPS traffic?
Yes, at the hostname level. The proxy sees the CONNECT request and can refuse the whole connection to a blocked host. It cannot block a single HTTPS path without decrypting traffic, and decryption fails against certificate-pinned apps.
Is a dead-proxy PAC entry better than a firewall rule?
They solve different problems. A PAC entry is fast and portable but editable by the user; a firewall rule is harder to override but coarser. Layer them – PAC for routing, firewall for enforcement – when a block genuinely has to hold.
Blocking an application through proxy settings is less about the toggle and more about picking the enforcement point that matches the app’s behavior, then verifying it under load on a proxy that doesn’t move. Start with the method your endpoint control allows, confirm the deny and the allow paths, and put a stable, dedicated IP behind whichever rule you rely on.
