Why does app HTTP traffic ignore the OS proxy by default?

[zeevenn]

On macOS, I use FlClash as the system HTTP/HTTPS proxy (127.0.0.1:7890). Other applications can use that proxy without a second configuration step.

In Tabularis, the New Connection picker initially showed very slow because of the no_proxy by default.

I understand why database and SSH traffic may need explicit, per-connection proxy controls. But why should app HTTP traffic—such as fetching the plugin registry—ignore the OS proxy unless I duplicate its host and port in Tabularis?

Is there a product reason for the current default? I’d appreciate understanding the intended behavior before proposing a change.

[debba]

Hi @zeevenn, good question. There's no real product reason behind this default; it's a side effect of how the proxy settings were introduced.

When proxy support landed, every HTTP client was built with .no_proxy() so that env variables or the system proxy couldn't override an explicit choice like "Disabled" or a connection with no proxy. For database and SSH traffic that makes sense: there we want deterministic, per-connection behavior. The catch is that the global settings only have "on/off", with no "use the system proxy" state. So "not configured" ends up meaning "direct", even for the plugin registry, updates and WebDAV.

I agree that app HTTP traffic should follow the OS proxy by default. What I have in mind:

• add a "System" option for the app HTTP scope (probably AI too) and make it the default
• keep "Custom" and "Disabled" as they are, with "Disabled" still forcing a direct connection
• leave database and SSH unchanged, with explicit per-connection control

If you'd like to open a PR along these lines it's very welcome, otherwise I'll open an issue to track it.

[zeevenn]

Thanks for the detailed explanation! The proposed approach makes sense to me.

I'd be happy to work on this and submit a PR. I'll take a look at the existing implementation and get started!

[zeevenn]

The current "on/off" switches are a bit confusing—it isn’t clear whether “on” means System or Custom.

What if we use "System / Custom / Disabled" for app requests and AI, defaulting to System, and "Custom / Disabled" for database and SSH? The per-connection settings can stay as they are.

[debba]

Yes, I agree, the on/off switch doesn't say what "on" actually means, and that's exactly where the confusion comes from.

Your split sounds right to me: "System / Custom / Disabled" for app requests and AI, defaulting to System, and "Custom / Disabled" for database and SSH. The OS proxy is really an HTTP-client concept, so it doesn't map cleanly onto raw database or SSH sockets, and there I'd rather keep the behavior explicit. Leaving the per-connection overrides as they are is fine too.

A couple of things to keep in mind while you work on it:

• "Custom" should keep meaning "use the global endpoint configured above", so we don't end up with a separate host/port per scope.
• Existing configs need a sensible migration. Today scopes is a map of booleans where a missing key means off. I'd map true to Custom, a missing key to the new default (System for app/AI, Disabled for DB/SSH), and an explicit false to Disabled, so nobody who deliberately turned it off suddenly starts going through a proxy. Please double check what the settings UI actually writes on save, though, because if it always persists every scope then explicit false and "never touched" look the same and we'll need to pick one.
• "Disabled" should still force a direct connection (keep the .no_proxy() there), while System just lets reqwest pick up the OS/env proxy.

Looking forward to the PR, thanks for picking this up!

[zeevenn]

I opened PR #1283 for this. Feedback welcome!