Connectivity Troubleshooting · Clash Technical Blog

FlClash v0.9.2: proxy changes on exit

On Windows, does the proxy remain after FlClash exits, or does your original proxy turn off? With v0.9.2, distinguish whether this run took over, record the settings, exit normally, restore the original values and verify real requests.

Read the articleBack to blog
  • FlClash
  • v0.9.2
  • System proxy
  • Windows
  • Normal exit
On this page
Published
Estimated reading time
About 8 minutes

On Windows, a system proxy remaining enabled after FlClash exits normally is not necessarily a cleanup failure. If the original proxy is disabled, that does not mean the app saved its settings and failed to restore them. Identify the setting’s source before retaining, disabling or restoring it.

A proxy left enabled and a proxy switched off differ

The FlClash v0.9.2 release describes preserving system proxies it did not set. This guide covers Windows 10/11, that version’s system-proxy switch and normal exit. TUN, WinHTTP, terminal environment variables and in-app proxies are separate settings.

Compare the actual settings before and after exit

What you seeWhat to check first
This run never tried to enable the proxy, or already disabled it successfully, and the original proxy remains after exitCheck whether it is still the server or script you need. Do not erase it merely because a switch is on.
FlClash was enabled, but the original company proxy or PAC did not return after exitThis version does not guarantee automatic restoration of previous values. Restore the required settings from your record.
FlClash has exited, but manual proxy remains enabled at its former local port and requests failCheck whether exit was actually normal, inspect the system settings and failure log, then restore the network configuration you need.
The browser works, but a terminal or one application failsCheck that program’s proxy source separately. The system-proxy switch does not represent every program.

Which settings does v0.9.2 preserve?

Entering this version’s system-proxy enable flow leaves a pending-disable record. Exit disables it only while that record remains. A successful earlier stop clears the record, so exit does not disable it again, just as when this run never attempted to enable it. This is not a check of the current Windows proxy’s ownership.

The fixed source calls the record _applied and sets it to true before calling startProxy. It records an attempt, not proof that the settings were written successfully. Enable and disable failures can both produce an update system proxy failed log.

On Windows, stopProxy uses WinINet to set connection options to PROXY_TYPE_DIRECT. It does not save and restore the previous server, PAC or all exceptions. Releasing a system proxy is different from restoring the original company-network configuration.

You cannot judge this solely by remembering whether you clicked the switch: systemProxy defaults to true in this version, and saved auto-run settings can enter the enable flow. The distinction is whether this process attempted to take over, not whether you remember clicking.

Record Windows values and the FlClash state first

Keep a comparison you can restore

  1. Record system settings

    Open Windows Settings → Network & Internet → Proxy. Separately record Automatically detect settings, setup-script and manual-proxy switches, plus the script address, server, port and exceptions. Record an originally direct connection too.

  2. Record the app and traffic-handling mode

    Confirm that FlClash is actually v0.9.2. Record the active configuration, actual proxy port, Dashboard “System proxy” and “TUN” states, and Auto run setting. Do not substitute a default port for the real value.

  3. Arrange an isolated comparison

    Choose a time when interruption is acceptable. Record the original TUN state, temporarily turn off “TUN”, and pause other features that automatically rewrite the same Windows settings. Keep the original proxy service running if you need it.

Without trusted original values, retain the current state and records. Use the original proxy tool or your organization’s recovery process, rather than an unfamiliar server. If Windows says the setting is managed and cannot be changed, use the existing administrator process instead of deleting registry entries to bypass it.

Check a run that never takes over the system proxy

Establish a clear new-process comparison

  1. First save FlClash with system proxy off

    In a controlled state, turn off FlClash “System proxy”, then select “Exit” in the tray to finish normally. Turning the switch off can itself release this run’s proxy, so record the original values first.

  2. Restore the original proxy baseline you need

    After FlClash exits, use the original tool or Windows Proxy settings to restore the recorded automatic-detection, script and manual-proxy values, then test a real request. Restore direct access if that was permitted originally; direct access is not an equivalent recovery for work that requires a proxy.

  3. Reopen without enabling system proxy

    Confirm that system proxy was saved off, watch the Auto run state, and leave the switch off throughout. Check the original path with the same target, then select tray “Exit”. Closing a window may only minimize it and is not the same test.

  4. Compare Windows settings and real requests

    Recheck automatic-detection, setup-script and manual-proxy switches, addresses and ports against the baseline, then test the same request. If settings change, record times, app state and logs instead of inferring the result from an icon.

The ordinary-exit protection in v0.9.2 applies to its corresponding flow. Retain the original proxy if it is unchanged and still needed. If it is disabled, keep reproducible conditions; one result cannot establish protection for other versions, every exit method or other software.

After taking over, restore the network values you need

To test FlClash system proxy itself, confirm that it is running and record its real port. Keep TUN off, then enable “System proxy”. Windows settings should match the FlClash local address 127.0.0.1 and that actual port. A highlighted switch alone does not prove the write succeeded.

Disable, restore and check again

  1. Stop this takeover

    Disable “System proxy” or select tray “Exit” normally, then wait for completion. If update system proxy failed appears, retain the log and current Windows values rather than repeatedly toggling the switch.

  2. Restore the configuration you originally needed

    If you originally used direct access, restore manual proxy to its original off state. For another server or PAC, restore each automatic-detection, script and manual-proxy switch, address, port and exception from your record, or let the original tool configure them. Do not assume exit restores them automatically.

  3. Verify real requests separately

    Access the original target on the same restored network and confirm the intended proxy or direct path. If only one program fails, inspect its configuration separately; do not reset WinHTTP, environment variables and every proxy layer together.

If another tool rewrites the system settings after FlClash takes over, this process’s record does not become a reliable test of current ownership. Complete setting changes one at a time and restore the required values. This is not automatic arbitration between clients.

Which results confirm completion?

Exit and recovery checklist

  • The full app version, real port, and original Windows automatic-detection, setup-script and manual-proxy values are recorded.
  • A run that never tried to take over, an earlier takeover attempt and a failed enable operation are distinguished, rather than relying on remembered clicks.
  • Exit was performed normally through the tray, not just by closing a window, forcing termination in Task Manager or running installer cleanup.
  • After exit or disabling, Windows settings meet the actual requirement. Original automatic detection, company server, PAC and exceptions are restored from records.
  • The same target works in a real request. Separate evidence is retained for remaining terminal, TUN or in-app proxy problems.

Installation and uninstallation follow another path: this version’s installer invokes a process with --clear-stale-proxy to handle stale proxy settings. That is different from the ordinary-exit queue described here. Do not run the argument to test this protection, or treat forced termination or a crash as proof that normal cleanup ran.

If settings still differ: recovery and reporting

Stop the comparison and restore the recorded Windows settings, FlClash system proxy and TUN states, and other temporary changes. Then check ordinary connectivity and targets requiring the original proxy. If that proxy service is unavailable, restore the service itself instead of merely entering the same broken address again.

If an update is needed for the feature, first make a separate backup of app data and Windows values, then update through the official project channel. For compatibility problems afterward, use the supported method to restore the corresponding version and backup. Rolling back does not restore external Windows settings automatically; do not share the only data directory between versions.

Report the full client and OS versions, auto-run state, system proxy and TUN states, this process’s enable history, normal-exit method, before-and-after addresses and failure time. Hide private servers, PAC credentials and subscription tokens in public evidence; retain original logs and backups locally.

References