Bug: MCP connections fail when system proxy is SOCKS via PAC on macOS

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

Summary

When macOS is configured to use a PAC file that returns a SOCKS proxy, Cursor’s MCP server connections fail with an “Invalid URL protocol” error. Browser-like traffic in Cursor continues to work, but MCP connections do not.

Environment

  • Cursor: 2.2.43
  • Network/proxy: System proxy via PAC returning SOCKS (example: SOCKS 127.0.0.1:8080)
  • Feature affected: MCP server connections (anything that requires the proxy to reach internal/VPN resources)

What happens

MCP servers fail to connect and Cursor shows an error similar to:

Invalid URL protocol: the URL must start with http: or https:

Notably:

  • Cursor’s browser UI / web content works normally through the SOCKS proxy.
  • Only MCP connections appear to fail.

Additional observations / workaround

If the PAC response is changed to include a fallback:

  • From:
    return "SOCKS 127.0.0.1:8080";
  • To:
    return "SOCKS 127.0.0.1:8080; DIRECT";

Then:

  • The Cursor browser UI continues to work via SOCKS.
  • MCP connections start working, but appear to do so via the fallback path (DIRECT), which isn’t always acceptable if the MCP server truly requires the proxy.

Why this seems relevant (hypothesis, not confirmed)

This looks like MCP is using a networking path that rejects PAC SOCKS entries unless they are expressed as http:// or https:// proxy URLs, whereas Chromium-based traffic can handle SOCKS host:port entries. If Cursor can confirm which stack MCP uses on macOS, that may explain the discrepancy.

Impact

This blocks MCP usage for users who rely on:

  • SSH dynamic port forwarding (ssh -D)
  • Corporate SOCKS proxies distributed via PAC files
  • Internal/VPN-only resources reachable only through SOCKS

Suggested direction

Any of the following would help:

  • Support SOCKS entries returned by PAC for MCP connections, or
  • Gracefully handle SOCKS host:port PAC results (e.g., by supporting SOCKS directly or providing a clear diagnostic + documented supported formats), or
  • Document current limitations and recommended configuration patterns.

References (for context)

Steps to Reproduce

  1. Configure macOS to use a PAC file that returns a SOCKS proxy for a target host/domain (example: SOCKS 127.0.0.1:8080).
  2. Ensure there is an HTTP-reachable MCP endpoint that is only reachable via that proxy (e.g., internal/VPN-only host).
  3. In Cursor, add/configure an MCP server pointing at that endpoint and click Connect.
  4. Observe the connection failure and error:
    • Invalid URL protocol: the URL must start with http: or https:

Expected Behavior

MCP server connections succeed when the system proxy is SOCKS via PAC, consistent with other network activity in Cursor.

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 2.2.43
VSCode Version: 1.105.1
Commit: 32cfbe848b35d9eb320980195985450f244b3030
Date: 2025-12-19T06:06:44.644Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Darwin arm64 25.2.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

2

Hey, thanks for the report.

This looks like a real bug. MCP connections likely use a different networking path (Node.js undici) that doesn’t fully support SOCKS entries from PAC files, unlike Chromium-based traffic in Cursor.

I’ve escalated this to the team for investigation. The references you provided (undici proxy limitations) are helpful for debugging.

As a temporary workaround, the SOCKS ...; DIRECT fallback you mentioned should work for cases where the MCP server is also reachable directly. For VPN-only resources, there’s no good workaround at this time unfortunately.

I’ll update this thread when there’s progress on a fix.

1 Like
4

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.