When Proxifier does not work, separate the failure into one of four layers: the proxy endpoint, the Proxifier rule, the application process, or name resolution. Changing all four at once makes the log harder to interpret and can introduce a connection loop.
Fastest triage
Proxy Checker first; application rule second; route verification last.
If Proxy Checker fails, fix the endpoint before editing application rules. If Proxy Checker passes but the app remains direct, inspect rule order and the actual process in Proxifier's Connections and Output panes.
Use the symptom to choose the first check
| Symptom | Most likely layer | First action |
|---|---|---|
| Proxy Checker fails | Address, port, protocol, authentication, network, or proxy health | Test the endpoint outside application rules |
| Proxy Checker passes but app shows the direct IP | Rule order or process mismatch | Inspect Connections and Output |
| App cannot connect through one protocol | Protocol capability | Compare SOCKS5, HTTPS CONNECT, and plain HTTP support |
| Hostnames fail but direct IPs work | Name resolution | Review Profile → Name Resolution |
| Everything slows or stops after adding a local proxy | Connection loop | Keep loop detection enabled and exclude the local proxy process |
| Only one helper or updater stays direct | Child process not covered by the rule | Add the exact process only when required |
Step 1: test the proxy independently
Open View → Proxy Checker or use the Check button in Proxy Server Settings. The official checker can test SOCKS4(A), SOCKS5, HTTPS, and HTTP endpoints and measure response time.
For the first test, leave Work through Proxifier disabled. That is the documented default. Enabling it causes the checker itself to follow Proxifier and is intended only for a specific scenario, such as a proxy that is not directly reachable.
Verify:
- Hostname or IP address.
- Port.
- Protocol selected in Proxifier.
- Username and password or enterprise authentication.
- Source-IP allowlist.
- Target host and port used by the checker.
- Local firewall and network reachability.
Step 2: confirm the proxy protocol
A common failure occurs when an HTTP proxy is added as HTTPS. Proxifier's documentation distinguishes plain HTTP support from HTTPS/CONNECT support:
- A plain HTTP proxy can process HTTP connections.
- A proxy that supports CONNECT on arbitrary ports can be configured as HTTPS.
- Many browser-compatible HTTP proxies allow HTTPS only on port 443 and cannot tunnel arbitrary application TCP connections.
- SOCKS5 is designed for general proxy routing and supports username/password authentication.
If a proxy works in a browser but fails in Proxifier, test whether it actually supports the selected protocol. Read SOCKS5 vs HTTPS in Proxifier before changing the application rule.
Step 3: read the matched rule in the Connections pane
The Connections pane shows the application, target, status, rule, proxy, and traffic. Proxifier evaluates rules from top to bottom. The first matching rule determines the action.
Check for these mistakes:
- A broad Direct rule appears above the intended proxy rule.
- The Default rule uses the proxy when it should be Direct.
- The application path does not match the executable that opened the connection.
- The target host or port criterion is narrower than intended.
- The rule is disabled.
- The application was started with manual proxification, which ignores ordinary rules for that process instance.
Step 4: identify the real process
Applications often use more than one executable:
- Launchers start the main process.
- Browsers use multiple processes.
- Updaters connect separately.
- Meeting and chat apps use helper processes.
- Python projects can use a virtual-environment interpreter instead of the system executable.
- Command-line shells start separate network tools.
Enable Verbose output, restart the application, and watch which executable creates the failing connection. Match that path instead of guessing from the shortcut name.
Step 5: verify the rule criteria
A connection must satisfy every populated rule criterion. If Applications, Target hosts, and Target ports all contain values, all three must match.
During diagnosis:
- Create one exact application rule.
- Leave Target hosts as Any.
- Leave Target ports as Any.
- Set the action to the verified proxy.
- Keep the rule above Default.
- Keep Default direct.
After the route works, narrow host and port criteria one at a time.
Step 6: check name resolution
When hostnames fail but numeric addresses work, review Profile → Name Resolution. Automatic detection is enabled by default. It can switch to proxy-side resolution if the system DNS service is unavailable.
Proxy-side resolution introduces placeholder addresses such as 127.8.*.*. IP-based rules no longer see the real destination address on the local computer. Use hostname-based rules and Verbose logging when that mode is active.
Read Proxifier DNS Leak Fix for a full local-versus-proxy resolution workflow.
Step 7: inspect the Output log
The Output pane supports four levels:
| Level | Use |
|---|---|
| Error Only | Program-critical and connection errors |
| Normal | Recommended ordinary view with connection open and close events |
| Verbose | Rule processing, DNS requests, and additional diagnostics |
| Debug | Extensive diagnostic output for deeper troubleshooting |
Use Verbose first. Save a file log when the error is intermittent. Proxifier can also create Debug and Traffic output, but traffic dumps can consume substantial disk space and may contain sensitive application data. Enable them only for a controlled diagnostic session.
Step 8: diagnose timeouts and refusals
Connection timeout
The connection was not established within the allowed time. Possible causes include an unreachable proxy, filtered port, overloaded endpoint, wrong network path, slow chain, or unavailable target.
Connection refused
A reachable host actively rejected the connection. Confirm the port and service, then check whether the endpoint is listening and whether the source is authorised.
Authentication failure
Confirm the username, password, authentication method, and whether the provider requires source-IP authorisation. HTTPS corporate proxies can use Basic, NTLM, Kerberos, or current-user credentials depending on configuration.
Target failure after proxy connection succeeds
The proxy can be reachable while the target is blocked, unavailable, disallowed by provider policy, or unsupported by the selected protocol.
Step 9: prevent infinite connection loops
A local proxy, antivirus, tunnel, or forwarding program can create a loop:
- The application connects.
- Proxifier redirects it to the local proxy.
- The local proxy opens its outbound connection.
- Proxifier captures that connection and redirects it back to the local proxy.
- The cycle repeats.
Proxifier includes Infinite Connection Loop Detection and Infinite Name Resolution Loop Detection. Keep both enabled unless you are resolving a documented false positive.
To fix a loop:
- Add a Direct rule for the local proxy or tunnel process.
- Do not proxify the local proxy's own outbound connection.
- Disable Handle Direct Connections in the local proxy workflow when the official documentation requires it.
- Disable proxy-side name resolution if a DNS loop is the trigger.
- Restart affected applications after changing the route.
Step 10: verify the corrected route
- Clear or save the current log.
- Restart the target application.
- Confirm the intended rule and proxy in Connections.
- Open IP Lookup from the routed application.
- Compare IPv4, IPv6, ASN, organization, and approximate location.
- For a browser, run WebRTC Leak Test and Browser Leak Test.
- Review DNS separately.
Escalation checklist
Collect enough information for support
- Proxifier version and edition.
- Windows version.
- Proxy address redacted as needed, port, and protocol.
- Proxy Checker result.
- Rule order.
- Actual executable path and process ID.
- Target hostname and port.
- Name-resolution mode.
- Relevant Verbose or Debug log lines.
- Whether a local proxy, VPN, antivirus, or tunnel is also active.
FAQ
Why does Proxy Checker pass but my application stays direct?
Proxy Checker validates the endpoint, not the application rule. Check rule order, the exact executable or child process, manual proxification, and whether another rule matches first.
Why does a proxy work in a browser but fail in Proxifier?
The server may be a plain HTTP proxy that handles browser HTTP or standard HTTPS ports but does not support arbitrary CONNECT tunneling. Add it with the correct protocol and test it with Proxy Checker.
Why does Proxifier show connection timeout?
The client could not establish the tested connection within the allowed time. Check address, port, protocol, firewall, upstream reachability, proxy health, and target availability.
Why does the wrong process bypass my rule?
Launchers, helpers, updaters, browsers, and child processes can use different executables. Use the Connections and Output panes to identify the process that actually creates the connection.
What causes an infinite connection loop in Proxifier?
A local proxy, tunnel, antivirus, or forwarding program can have its outbound connection captured and redirected back into itself. Exclude that process with a Direct rule and keep loop detection enabled.
What log level should I use for troubleshooting?
Use Verbose to see rule processing and DNS requests. Use Debug only when the extra detail is needed, because it produces much more output.