Codebase index not using proxy server (remote ssh) even though network diagnostics pass

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Codebase index not using proxy server even though network diagnostics pass, using remote ssh to linux from linux.
Index log says:
025-09-14 18:23:34.453 [error] Error Checking Connection: [unavailable] getaddrinfo EAI_AGAIN repo42.cursor.sh
2025-09-14 18:23:34.454 [info] Creating Indexing Repo client: https://repo42.cursor.sh
2025-09-14 18:23:34.454 [info] Creating repo client with backend url: https://repo42.cursor.sh
2025-09-14 18:24:38.453 [warning] Retrying handshake with timeout 128000. Error: [unavailable] getaddrinfo EAI_AGAIN repo42.cursor.sh
2025-09-14 18:24:38.454 [error] Handshake failed:
2025-09-14 18:24:38.454 [error] Error: timeout in handshake with retry
etc..
So it’s trying to lookup dns and failing which means it’s not respecting the proxy.
I also tried to manually set http proxy in the config but it’s not affecting anything.

Is there a config option i’m missing? maybe i can tunnel the index back through my own machine instead of forcing the development machine to get to the internet? – update i did tcpdump on the remote machine and it doesn’t send anything at all or even try yet network diags pass

Steps to Reproduce

use ssh to linux which has a proxy server set in https_proxy env. Network diagnostics work 100% but i’m not sure if they are testing the remote machine or mine.
Everything else works but the indexing

Operating System

Linux

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.5.11
VSCode Version: 1.99.3
Commit: 2f2737de9aa376933d975ae30290447c910fdf40
Date: 2025-09-05T03:48:32.332Z
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Linux x64 6.6.87.2-microsoft-standard-WSL2

Does this stop you from using Cursor

No - Cursor works, but with this issue

anyone know of a way to set the cursor-server on the remote ssh host to use a proxy? the remote host i’m using the ‘remote ssh’ extension to ssh to has no internet access other than through a proxy, and it seems like the indexing service needs internet access on that server itself and not my client, and since the model can’t see any of the code index it’s really hurting the output

hi @f00z we are looking into it.

Thank you. for example I have in the /etc/profile.d/ a script to add the env variables like so:
export http_proxy=“http://10.201.1.253:3128/”
export https_proxy=“http://10.201.1.253:3128/”

these are available to all users and it works for all the terminals, etc.. needs sudo -i (which the ai agent doesn’t realize if it wants to install a package with apt for example)
The cursor-server i’d expect to see the env variables as they show up properly declared when i log in as the user that the remote ssh is using.

I tried adding this to the settings json like
“remote.SSH.httpsProxy”: “http://10.201.1.253:3128/”

but that doesn’t seem to do anything either.

It did download and install the cursor-server no problem but i’m not sure if my client uploads that or it ‘wgets’ it from the internet somehow on install?

Any updates on this? seems like it’d be a really simple fix to check the proxy variable env on the remote server or at least have an option in cursor config to put the proxy for the indexing?

Hi @f00z, could you confirm which settings.json you set the remote.SSH.httpsProxy in? This will need to be on the local machine, not on the remote machine.

Could you also set the remote.SSH.httpProxy setting?

After setting it, could you run the “Kill Remote Server and Reload Window” command?

If it still doesn’t work, could you share your logs from the “Remote - SSH” output panel so we can take a closer look?

image

Tried setting http proxy also. I see the remote ssh is sending it:

in the logs: Sending command request: {“command”:“echo”,“args”:[“1”],“env”:{“HTTP_PROXY”:"http://10.201.1.253:3128/“,“http_proxy”:“http://10.201.1.253:3128/”,“HTTPS_PROXY”:“http://10.201.1.253:3128/”,“https_proxy”:“http://10.201.1.253:3128/”},”

But,
2025-09-23 10:54:04.798 [info] Handshake start
2025-09-23 10:54:04.802 [error] Error Checking Connection: [unavailable] getaddrinfo EAI_AGAIN repo42.cursor.sh
2025-09-23 10:54:04.803 [info] Creating Indexing Repo client: https://repo42.cursor.sh
2025-09-23 10:54:04.803 [info] Creating repo client with backend url: https://repo42.cursor.sh
2025-09-23 10:55:08.803 [warning] Retrying handshake with timeout 128000. Error: [unavailable] getaddrinfo EAI_AGAIN repo42.cursor.sh
2025-09-23 10:55:08.803 [error] Handshake failed:
2025-09-23 10:55:08.803 [error] Error: timeout in handshake with retry

etc.. just keeps going

This means it’s not using or respecting the proxy as the proxy is the only internet access.

It could tunnel it back to my client, is there a way to do that?

Any workarounds for this? I’ve tried a bunch of config settings

Hi @f00z, I have asked the team to look into this.

Hi @f00z , can you try disabling HTTP/2 support in your settings and see if that makes any difference? The networking library we use might have some issues with HTTP/2 proxy support.

OK i’ll try it, but the network diagnostics pass. If i change it on my client does that change it on the ‘cursor server’ on the remote server, i.e. the nodejs process you guys install on the remote host i’m sshing to in order to work on the code? It seems like that server is what is not working, everything from my client side works fine.

Hi @f00z, yes – that setting is respected for the remote server.

OK you are right switching it to http/1.1 made it use the proxy variables (either on the remote server or the ones i set in the json settings file i’m not sure because they are the same). So this fixed it but now it’s using 1.1 instead of 2. I suppose this is OK, but the http/2 wasn’t even attempting to use the proxy it just ignored the variables entirely.
I‘m using it with 1.1 now, hopefully it doesn’t slow things down considerably (although the new 1.7 that somehow got pushed to me seems a lot slower in general than the 1.6 so it’ll be hard to tell)

1 Like

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