Using Surge Together with Whistle

Surge is my go-to proxy tool—flexible rules plus an open API make automation easy. At work, though, I still rely on the company’s OA client and Whistle for HTTP debugging. During a break I explored how to make them coexist cleanly.

Current Setup

• Personal Macs: Surge handles all proxies and “over-the-wall” access.
• Work Mac:
  1. Company OA client handles internal network, authentication, and internet access.
  2. Whistle + SwitchyOmega handles web debugging.

Chrome proxies through Whistle; unmatched traffic falls back to the system proxy.

Improvements I Already Have

• Alfred workflow for Whistle to switch rules quickly.
• Alfred workflow for Surge to toggle modes/policies fast.

Pain Points

1. SwitchyOmega requires manual toggles.
2. Whistle sometimes crashes (partly corporate network instability, partly heavy load).
3. The OA client handles external sites but is slower than my personal proxies, and some sites are blocked.

Goal: run OA + Surge + Whistle together, dropping SwitchyOmega.

Benefits

1. Eliminate SwitchyOmega—let Surge distribute traffic for Chrome, Safari, etc.
2. External requests that don’t need Whistle go straight through Surge for better speed.
3. Easily choose between OA routes and personal nodes for internet access.
4. Toggle Whistle debugging on/off with a rule or module.

Solution

1. Remove SwitchyOmega from Chrome. Keep the OA client running, enable Surge, but disable Surge enhanced mode.
2. Update Surge config:
   • Add a Whistle proxy node:

     Dev-Whistle-local = http, 127.0.0.1, 8899
     

   • Add rules routing browser processes through Whistle:

     PROCESS-NAME,Google Chrome*,Dev-Whistle-local
     OR,((PROCESS-NAME,Safari*), (PROCESS-NAME,/Library/Apple/System/Library/StagedFrameworks/Safari/WebKit.framework/Versions/A/XPCServices/com.apple.WebKit.Networking.xpc/Contents/MacOS/com.apple.WebKit.Networking), (PROCESS-NAME,/System/Library/Frameworks/WebKit.framework/Versions/A/XPCServices/com.apple.WebKit.Networking.xpc/Contents/MacOS/com.apple.WebKit.Networking)),Dev-Whistle-local
     PROCESS-NAME,firefox*,Dev-Whistle-local
     PROCESS-NAME,Microsoft Edge*,Dev-Whistle-local
     

Notes

• Place these process rules after domain-based ones so sites like Google/GitHub still hit the desired proxy first.
• Safari is tricky—Surge matches on proc_pidpath(), so versions live in different locations. Use an OR expression to cover them.
• Since Surge’s HTTP API doesn’t edit rules directly, wrap these rules in a module and toggle via module API/UI.

Result

• Workflows no longer need SwitchyOmega. When I need Whistle, I enable the module and all browsers route through it automatically.
• The OA client can’t proxy every app, so Gmail in Mail.app used to fail. With Surge managing proxies, I can add a rule for Mail and Gmail works again.

Drawbacks

• Enhanced mode must stay off; otherwise corporate services fail auth (they expect traffic to originate from the OA proxy).
• I don’t list every corporate domain; the final rule defaults to DIRECT to ensure internal access continues to work.
• With Chrome fully proxied to Whistle, requests that need an external proxy must be handled by earlier rules; otherwise they’ll go direct.

What About Enhanced Mode?

It’s possible if you map every corporate domain to the OA proxy—but that’s labor-intensive and brittle. I don’t recommend it.

Final Thoughts

After some tweaking, Surge and Whistle coexist nicely alongside the corporate OA client. Safari and other apps can now route through Whistle without juggling Chrome extensions.