Flaky Remote Debugging under WSL2 with Parcel/React project, with ECONNREFUSED to 127.0.0.1

I am trying to make the switch to WSL (the newer version, WSL2) on Windows 10 since the build speeds are much faster, but being able to debug is the missing link.

I have created a barebones test project to try to run down why my breakpoints aren't working in WSL. I'm using Parcel for a bundler, VSCode with version 2.9.1 of `vscode-firefox-debug`

After an hour running it down I think it's likely that it is something about the way "localhost" works in WSL.

Debugging works fine for me when running this project on Windows10 outside WSL. When running under WSL2 I'm able to see logging output from Firefox but the breakpoints often don't work.

In the course of writing this issue, the WSL remote debugging mysteriously started working with no rhyme or reason, no change on my part, so I have included logs below from both a non-working and working run under WSL.

When running outside WSL, I can see even from the console.log's that the source maps are working correctly, because it prints "main.tsx:19" next to the console print statement

When running under WSL2, Firefox itself (inside the firefox console window) is printing Main.tsx next to the console statement, but in VSCode I see the bundle name instead (main.186cb047.js). So the fact that the breakpoints aren't working is indeed a source-map issue, but Firefox is able to use the sourcemaps fine, so it's more of an issue of VSCode getting the source maps.

In cases where it fails to work, the Diagostic output from vscode-firefox-debug prints far less lines. In cases where it's working properly, the output will contain the line

```
DEBUG|006.049|PathConversion: Converted url http://localhost:1234/main.tsx to path D:\mike\dev\simple-react-test\main.tsx
```

whereas in cases where it's not working, it never prints any line about main.tsx, but only about the bundles:

```
DEBUG|006.259|PathConversion: Converted url http://localhost:1234/main.186cb047.js.map to path vscode-remote://wsl%2Bubuntu/home/mike/simple-react-test/main.186cb047.js.map
ERROR|008.273|net: HTTP GET failed: Error: connect ECONNREFUSED 127.0.0.1:1234
DEBUG|008.274|PathConversion: Converted url http://localhost:1234/main.186cb047.js to path vscode-remote://wsl%2Bubuntu/home/mike/simple-react-test/main.186cb047.js
Download the React DevTools for a better development experience: https://reactjs.org/link/react-devtools
```

As mentioned, debugging mysteriously started working under WSL during these experiments at which point the WSL console output looked like the windows output.

So the question is, why under WSL does it sometimes not try to do the PathConversion for main.tsx?

Maybe the `ECONNREFUSED` in the logs above is the answer? I'm running parcel's server on localhost:1234. When running outside WSL, 127.0.0.1 is equivalent to localhost, but under WSL2, if parcel is serving on localhost:1234 and I try to browse to 127.0.0.1:1234 I get "unable to connect".

So perhaps the crux of this bug is that there's an assumption somewhere that 127.0.0.1 is equivalent to localhost, which is untrue in this environment. I don't know where that assumption is being made though.

My other thought is that maybe the last lines of these logs are a hint :

```
ERROR|007.998|EnvironmentAdapter: Unexpected function grip in function environment: {"displayName":"parcelRequire<[\"main.tsx\"]<"}
ERROR|007.999|EnvironmentAdapter: Unexpected function grip in function environment: {"displayName":"parcelRequire<[\"main.tsx\"]

barebones React project、localhost:1234 上の Parcel、WSL2、vscode-firefox-debug を使って問題を再現することから始め、動作する診断ログと失敗する診断ログを比較します。main.tsx の source-map パス変換と ECONNREFUSED リクエストを調査し、source mapping が異なる理由を特定します。完了の条件は、接続失敗なしで WSL2 上の信頼できるブレークポイントと main.tsx パスが得られることです。

索引モデルが issue の本文から書いたものです。