Skip to content
Article / 6 min read

Proxifier + SOCKS5: Route Only the Apps You Choose Through a Proxy

Proxifier lets you apply a SOCKS5 proxy per application instead of system-wide. How to add the proxy, decide where DNS resolves, write proxification rules that behave, and fix the leaks that catch most users.

Most proxy setups are all-or-nothing. Either you change a system setting and everything goes through the proxy, or you configure a single application and everything else ignores it. Proxifier sits in the middle: it intercepts outbound connections at the socket level and applies rules - this application uses the proxy, that one goes direct, this host is blocked entirely.

That makes it a natural fit for SOCKS5, because SOCKS5 can carry any TCP traffic, not just HTTP. This guide covers the setup steps, the DNS decision that causes most leaks, and the rules that stop you proxying things you did not mean to.

One caveat before you start: menu names shift slightly between Proxifier versions and platforms. The concepts below are stable, so if a label does not match exactly, look for the nearest equivalent.

What Proxifier gives you that system settings cannot

  • Application-level routing. Send one browser through the proxy and leave everything else direct.
  • Target-level routing. Proxy traffic to specific domains or IP ranges and send the rest direct.
  • Protocol-agnostic proxying. Any TCP application can be routed through a SOCKS5 proxy, even one with no proxy settings of its own.
  • Chaining. Route through a proxy and then through another hop.
  • A traffic log. You can see exactly which connection went where, which is invaluable when something leaks.

Before you start: assemble the proxy details

From your proxy provider you need:

  • Hostname or IP address, plus port.
  • Protocol: SOCKS5.
  • Username and password, if authentication is required.
  • Whether the endpoint gives you a rotating IP or a sticky session, because that decides whether stateful multi-step flows will work.

Decide up front whether DNS should resolve at the proxy. With SOCKS5, resolving hostnames on your own machine is the most common source of location leaks. Most providers expose remote DNS either through a client-side setting or a username flag.

Step 1: Add the SOCKS5 proxy to Proxifier

  1. Open the Profile menu and choose Proxy Servers.
  2. Click Add.
  3. Enter the address and port, and set the protocol to SOCKS Version 5.
  4. If the proxy requires authentication, enable it and enter the credentials.
  5. Use the built-in Check button to confirm the proxy responds before you build any rules on top of it.

If the check fails, the cause is almost always one of three things: a wrong port, credentials that need URL encoding because of special characters, or a provider that restricts connections to whitelisted IP addresses.

Step 2: Decide how DNS is handled

This is the setting most people skip, and it is the one that quietly generates leaks. In the name resolution settings, typically under Profile then Name Resolution, you choose between resolving hostnames locally or at the proxy.

  • Resolve through the proxy when your goal is to keep your real location and DNS queries out of the picture. This is the SOCKS5 equivalent of using socks5h:// instead of socks5://.
  • Resolve locally only when you specifically need local DNS behaviour, such as split-horizon names on a corporate network.

If a site sees geolocation matching your real location rather than your proxy's, this is the first setting to inspect.

Step 3: Write proxification rules

Rules live under Profile then Proxification Rules. They are evaluated in order and the first match wins, so ordering matters more than any individual entry.

A sensible starting structure:

  1. Direct for local addresses. Loopback and your LAN should never be proxied.
  2. Direct for the proxy server itself. Without this, some configurations try to send proxy traffic back through the proxy.
  3. Proxy for the specific applications you care about. One rule per executable, with the action set to your SOCKS5 proxy.
  4. Direct or Block for everything else. Choose deliberately which of the two you want as the default.

Each rule can match on:

  • Applications - executable names or paths.
  • Target hosts - domains, wildcards, or IP ranges.
  • Target ports - useful for sending only, say, port 443 through the proxy.

Keep the list short. A rule set with thirty overlapping entries is impossible to reason about when something breaks.

Step 4: Verify that traffic is going where you think

Verification has three parts:

  1. In the traffic log, confirm the connection you just made is attributed to the SOCKS5 proxy rather than to Direct.
  2. From the application, check the IP that a public IP-check page reports.
  3. From the command line, compare a direct request with a proxied one:
# Direct
curl -s https://api.ipify.org; echo

# Through the SOCKS5 proxy with remote DNS resolution
curl -s --proxy socks5h://user:[email protected]:1080 https://api.ipify.org; echo

If those two commands disagree, your rule is not matching the application you thought it was matching. That is usually an ordering problem, or a rule that matches a launcher rather than the process doing the networking.

Common Proxifier + SOCKS5 problems

  • A rule matches the launcher, not the process. Browsers and runtimes often spawn a separate child process that opens the sockets. Match on the process that actually connects.
  • DNS leaks. Covered above, but it remains the number one cause of "my IP changed, yet the site still knows where I am."
  • The proxy client itself gets proxied. An easy loop to create with an over-broad application rule.
  • Conflicts with a VPN or an antivirus filter driver. Layered network interception is fragile. If a VPN client is running, test Proxifier on its own first.
  • Sandboxed applications. Apps running in a restricted sandbox may not be interceptable through the same mechanism as ordinary desktop software.

When you do not need Proxifier at all

If only your browser needs the proxy, browser-level configuration is simpler. If you need SOCKS5 for command-line tools, an SSH dynamic forward combined with a wrapper such as proxychains does a similar job. If you want every app on the device routed and you do not need per-app rules, a VPN is the cleaner tool. Proxifier earns its place specifically when the requirement is selective, per-application routing.

Takeaway

Add the SOCKS5 proxy first and confirm it responds, decide deliberately whether DNS resolves locally or at the proxy, then keep the rule list short and ordered so the first match is always the one you expect. Verify with the traffic log and with an IP check - and treat any disagreement between the two as a rule-matching bug rather than a proxy problem.