Dart DevTools fails to connect in vscode-serve-web (Connection Refused to 127.0.0.1)

[heunghingwan]

Environment:

• VS Code Version: 1.119.0
• Dart/Flutter Extension Version: v3.134.0
• Start Command: code serve-web
• OS: Linux

Description:

When using VS Code via serve-web (browser-based), the Dart/Flutter extension attempts to launch or connect to DevTools using 127.0.0.1. However, in a web-based IDE sandbox, 127.0.0.1 refers to the user's local machine (client) rather than the remote host where the DevTools server is actually running.

Steps to Reproduce:

1. Launch VS Code using code serve-web or a similar web-based hosting.
2. Start a Flutter/Dart project.
3. Click on "Flutter" from the Activity Bar.
4. The embedded Webview or the redirected URL fails because it points to http://127.0.0.1:9100.

[kenzieschmoll]

CC @DanTup

[DanTup]

@heunghingwan are you able to provide some exact steps to reproduce this, and more details about exactly what the failure you see is?

I tried this out on GitHub Codespaces, which is web-hosted with a remote backend, and because of how auth works there I did have to set the exposed ports to "Public" and then accept this warning:

However once I did, the Flutter sidebar appears correctly for me, suggesting the URL is being correctly mapped to the public URL provided by the VS Code APIs:

I expect if you're self-hosting, you wouldn't have this auth step sat in the way.

Can you confirm the exact command you're using to serve VS Code, and how you're connecting to it (for example are you performing any of your own port forwarding or proxying, or connecting directly to the remote machine and letting VS Code do all port forwarding)?

Thanks!

[heunghingwan]

I am running VS Code Server as a systemd service with the following configuration:

Command: /snap/code/current/usr/share/code/bin/code serve-web --log info --accept-server-license-terms --host 0.0.0.0 --without-connection-token --server-data-dir /opt/code-server/server-data/ --cli-data-dir /opt/code-server/cli-data/

Network Setup:

• The server is hosted in an internal network.
• Traefik is used as a reverse proxy to handle SSL termination.
• Authentication is disabled (since it's an internal environment).
• I have also tested accessing the IDE directly (bypassing Traefik) via the server's IP, and the issue persists.

Regardless of how I access the IDE, the Flutter/Dart extension consistently attempts to connect to DevTools via http://127.0.0.1:9100.

In a serve-web architecture, 127.0.0.1 in the client's browser points to the user's local machine, not the remote server. Since the IDE is being served on 0.0.0.0, the extension should ideally use the server's IP or the current browser's origin to establish the DevTools connection, rather than hardcoding localhost.

Would it be possible to allow the DevTools host to be configurable, or have the extension detect the host based on the current window location?

[DanTup]

the extension should ideally use the server's IP or the current browser's origin to establish the DevTools connection, rather than hardcoding localhost

This is what should be happening - this is handled by a VS Code API that has access to the environment (env.asExternalUri()). It's job is to map a local URL into something that is accessible to wherever the front-end is (and if port forwarding needs setting up, it should handle that).

Could you try the following:

• Run the Dart: Capture Logs command from the command palette
• Run the DevTools: Open in Browser command
• Click Cancel on the logging notification to stop logging and open the log file

This should capture a log that contains some info about the mapping of the URIs. Could you share this - as well as confirming whether we opened the correct or incorrect URL when spawning DevTools in the browser?

[heunghingwan]

!! ⚠️ PLEASE REVIEW THIS LOG FOR SENSITIVE INFORMATION BEFORE SHARING ⚠️ !!
Dart Code extension: 3.134.0
Flutter extension: 3.134.0 (activated)

App: Visual Studio Code
App Host: server-distro
Remote: <url>:443
Host Kind: server-distro
Version: linux 1.119.0

Workspace type: Flutter (LSP)
Workspace name: wh

Dart (3.11.5): /home/<user>/fvm/versions/stable/bin/cache/dart-sdk
Flutter (3.41.9): /home/<user>/fvm/versions/stable (No device)


Logging Categories:
    General, Analyzer, AnalyzerTiming, CommandProcesses, DartTest, DartToolingDaemon, DAP, VmService, DevTools, FlutterDaemon, FlutterRun, FlutterTest, FlutterWidgetPreview, WebDaemon

Tue May 12 2026 [23:36:02 GMT+0800 (香港標準時間)] Log file started
[下午11:36:27] [General] [Info] Opening external URL: http://127.0.0.1:9100/home?cacheBust=dart-3.11.5-flutter-3.41.9&ide=VSCode&ideFeature=command&theme=dark
Tue May 12 2026 [23:36:38 GMT+0800 (香港標準時間)] Log file ended

browser tries to connect to http://127.0.0.1:9100/ as shown in the log

[DanTup]

@heunghingwan thanks! Unfortunately that was less helpful than I'd hoped - it turns out we don't log as much in this case as I thought.

I will try to make some improvements to the logging, but in the meantime could you confirm:

• Is it just those one Flutter sidebar panel that's failing, or do all of the others (such as the Property Editor, or if you try to open the Widget Inspector?)
• If you try to run your Flutter app (using the web-server device), does that work?
• In the log, where it says Remote: <url>:443 where I presume you removed the url, was that the correct URL that you see in the browser?
• If you manually change the IP address in the address bar when you tried to open DevTools in the browser, does it actually load? (and if not, in what way does it fail - is the port not accessible, or does the frontend load, but then fail to connect to backend services)

[heunghingwan]

• Is it just those one Flutter sidebar panel that's failing, or do all of the others (such as the Property Editor, or if you try to open the Widget Inspector?)

All of them fail — they all try to connect to 127.0.0.1.

• If you try to run your Flutter app (using the web-server device), does that work?

Yes, it works. I can run the app normally in Chrome on the server.

• In the log, where it says Remote: <url>:443 where I presume you removed the url, was that the correct URL that you see in the browser?

Yes, the URL it picks up is correct.

• If you manually change the IP address in the address bar when you tried to open DevTools in the browser, does it actually load? (and if not, in what way does it fail - is the port not accessible, or does the frontend load, but then fail to connect to backend services)

I can't connect from my local device because the DevTools server listens only on the loopback interface (127.0.0.1). If I open it in a browser directly on the server, it works fine.

[DanTup]

@heunghingwan thanks - I'm adding some more logging and will publish a pre-release version of the extension tomorrow that might help.

In the meantime, two other things that might help:

1. Does the port (9100) show up in the "Ports" pane?
2. If you flutter run -d web-server in the built-in terminal (from your local client), does the port it runs on also appear in the Ports pane, and if so, can you access that from the local (client) browser? (note: the Flutter app might fail to start without the Dart Debug extension, but you may be able to at least check that the port was accessible)

[DanTup]

@heunghingwan I pushed a pre-release version of the Dart extension with additional logging - how ever I was also able to reproduce this here. It appears that VS Code doesn't provide any port forwarding (or mapping or URLs) when using code serve-web, it only works for other kinds of remote workspaces (like SSH, Docker, Codespaces, etc.).

I've opened an issue at microsoft/vscode#316209 about this.

The only workaround I can think of in the meantime is to use VS Code's built-in tunnelling (see https://code.visualstudio.com/docs/remote/tunnels), which does support the port forwarding (and I think as an added benefit, you could choose to either access it via the browser, or using a local VS Code install).

Edit: I guess another option could also be to use the SSH remoting option if you're able to access the remote server over SSH, although I think that would require you use a local VS Code client (not a browser).