Cannot connect to Compute

[winnieshen96]

Does this occur consistently? Yes
Repro steps:

1.Connect to a compute instance on AML via VS code

Action: Resolver.resolve
Error type: 335
Error Message: Cannot connect to Jupyter Lab Terminal. Please try again.

Version: 1.5.2026073009
OS: win32
OS Arch: x64
OS Release: 10.0.26100
Product: Visual Studio Code
Product Version: 1.131.0
Language: en
UTC time: Tue, 04 Aug 2026 17:40:33 GMT

Error log:

ERR [LocalProcess0][resolveAuthority(amlext,1)][30823ms] returned an error
TerminalError: Cannot connect to Jupyter Lab Terminal. Please try again.
at u.checkForBadGateway (...)
at t.ComputeInstanceRemoteTargetLegacy.ensureIsConnectable (...)
at t.ComputeInstanceRemoteTargetLegacy.getConnectionHub (...)

[Siglud]

Please follow this documents to do some trouble shooting to make sure your Jupyter terminal is working for your current network.

[winnieshen96]

FanH (@Siglud) We have checked everything we could and our networking is not the culprit here - Both privatelink.api.azureml.ms and privatelink.notebooks.azure.net resolve correctly from client machines.

[Siglud]

FanH (@Siglud) We have checked everything we could and our networking is not the culprit here - Both privatelink.api.azureml.ms and privatelink.notebooks.azure.net resolve correctly from client machines.

Please test the following and share the outcome:

• Open the Jupyter terminal in your Jupyter lab in the portal for that Compute to confirm it’s working
• Use the stable version of our extension to connect to the remote; the latest stable version should be v1.4.8
• Click on the Use Exec Server option in the settings to see whether it allows you to connect to the remote

Thanks!

[winnieshen96]

FanH (@Siglud) Jupyter lab terminal doesn't work either. I have submitted a ticket to Microsoft Support. But I would like to keep this issue open for visibility, since other companies are facing this issue too.

[M-I-Dx]

FanH (@Siglud) same here. None of the methods that allow connecting to the VM are working. I too have raised a ticket with Microsoft for the same.

[winnieshen96]

The issue has been resolved for my company. We ended up identifying a root cause in the firewall: We found that traffic from the MLWorkspace network on port 5831 was previously matching an allow rule using port udp-5831 and being classified as an unknown application. Starting earlier this week, the firewall began identifying the same traffic as QUIC, which is currently explicitly blocked by policy. We adjusted the rule order and the connection worked again.