connect ECONNREFUSED 127.0.0.1:4200

[Frikki]

When I launch a server on http://localhost:4200 (localhost resolves to 127.0.0.1), OpenAPI (Swagger) Editor attempts to connect to http://127.0.0.1:4200, which resolves in error:

connect ECONNREFUSED 127.0.0.1:4200

The issue isn’t the extension per se but due to our organization’s security rules. If I launch the server explicitly on http://127.0.0.1:4200, I won’t get the error.

However, I expressly specified the server URL in the openapi.yaml file to be http://localhost:4200, so I would expect the extension to request that address, not the resolved address.

OpenAPI (Swagger) Editor should use the exact instructions from the openapi.yaml file.

[ak1394]

Could you please clarify if you're using a "TryIt" feature of the extension or "Try It Out" from SwaggerUI documentation preview window?

[Frikki]

@ak1394 I use “Try it”

[ak1394]

Looks like we need to get a bit more of the information regarding your setup. All HTTP clients have to resolve a hostname to an IP address to perform the connection, and that's what happens under the hood in this extension as well. Let's try to figure out details of your configuration, so we can see what can be done about it.

What OS you're on? If you 'ping' localhost what address does it resolve to? Do you have 'curl' command on your system so we can diagnose issue further?

[Frikki]

@ak1394

macOS Ventura 13.4
localhost => 127.0.0.1
curl available.

[ak1394]

Thanks! Could you do the following to help further diagnose the issue:

1. Launch your server on http://localhost:4200

2. Run netstat command in the terminal to check where your server is listening for the incoming connections: netstat -na -f inet -p tcp | grep LISTEN

3. Run curl to try connecting to your server curl --verbose http://localhost:4200 and then re-run it trying to connect to 127.0.0.1 instead curl --verbose http://127.0.0.1:4200

4. Restart your server on http://127.0.0.1:4200 and repeat steps 2 and 3

Please send the output of the commands in steps 2, 3 and 5

[Frikki]

1.a Server launched on http://localhost:4200
2.a netstat -na -f inet -p tcp | grep LISTEN

tcp4       0      0  127.0.0.1.51388        *.*                    LISTEN     
tcp4       0      0  127.0.0.1.45623        *.*                    LISTEN     
tcp4       0      0  127.0.0.1.56436        *.*                    LISTEN     
tcp4       0      0  127.0.0.1.56435        *.*                    LISTEN     
tcp4       0      0  127.0.0.1.50605        *.*                    LISTEN     
tcp4       0      0  127.0.0.1.9000         *.*                    LISTEN     
tcp4       0      0  100.64.0.1.9000        *.*                    LISTEN     
tcp4       0      0  127.0.0.1.7335         *.*                    LISTEN     
tcp4       0      0  127.0.0.1.18412        *.*                    LISTEN     
tcp4       0      0  127.0.0.1.44950        *.*                    LISTEN     
tcp4       0      0  127.0.0.1.44960        *.*                    LISTEN     
tcp4       0      0  127.0.0.1.16494        *.*                    LISTEN     
tcp4       0      0  127.0.0.1.15393        *.*                    LISTEN     
tcp4       0      0  127.0.0.1.15292        *.*                    LISTEN     
tcp4       0      0  *.5000                 *.*                    LISTEN     
tcp4       0      0  *.7000                 *.*                    LISTEN   

3.a.1 curl --verbose http://localhost:4200

*   Trying 127.0.0.1:4200...
* connect to 127.0.0.1 port 4200 failed: Connection refused
*   Trying [::1]:4200...
* Connected to localhost (::1) port 4200 (#0)
> GET / HTTP/1.1
> Host: localhost:4200
> User-Agent: curl/7.88.1
> Accept: */*
> 

3.a.2 curl --verbose http://127.0.0.1:4200

*   Trying 127.0.0.1:4200...
* connect to 127.0.0.1 port 4200 failed: Connection refused
* Failed to connect to 127.0.0.1 port 4200 after 25 ms: Couldn't connect to server
* Closing connection 0
curl: (7) Failed to connect to 127.0.0.1 port 4200 after 25 ms: Couldn't connect to server

1.b Server launched on http://127.0.0.1:4200
2.b netstat -na -f inet -p tcp | grep LISTEN

tcp4       0      0  127.0.0.1.59966        *.*                    LISTEN     
tcp4       0      0  127.0.0.1.59960        *.*                    LISTEN     
tcp4       0      0  127.0.0.1.4200         *.*                    LISTEN     
tcp4       0      0  127.0.0.1.51388        *.*                    LISTEN     
tcp4       0      0  127.0.0.1.45623        *.*                    LISTEN     
tcp4       0      0  127.0.0.1.56436        *.*                    LISTEN     
tcp4       0      0  127.0.0.1.56435        *.*                    LISTEN     
tcp4       0      0  127.0.0.1.50605        *.*                    LISTEN     
tcp4       0      0  127.0.0.1.9000         *.*                    LISTEN     
tcp4       0      0  100.64.0.1.9000        *.*                    LISTEN     
tcp4       0      0  127.0.0.1.7335         *.*                    LISTEN     
tcp4       0      0  127.0.0.1.18412        *.*                    LISTEN     
tcp4       0      0  127.0.0.1.44950        *.*                    LISTEN     
tcp4       0      0  127.0.0.1.44960        *.*                    LISTEN     
tcp4       0      0  127.0.0.1.16494        *.*                    LISTEN     
tcp4       0      0  127.0.0.1.15393        *.*                    LISTEN     
tcp4       0      0  127.0.0.1.15292        *.*                    LISTEN     
tcp4       0      0  *.5000                 *.*                    LISTEN     
tcp4       0      0  *.7000                 *.*                    LISTEN   

3.b.1 curl --verbose http://localhost:4200

*   Trying 127.0.0.1:4200...
* Connected to localhost (127.0.0.1) port 4200 (#0)
> GET / HTTP/1.1
> Host: localhost:4200
> User-Agent: curl/7.88.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< vary: RSC, Next-Router-State-Tree, Next-Router-Prefetch, Accept-Encoding
< cache-control: no-store, must-revalidate
< x-powered-by: Next.js
< content-type: text/html; charset=utf-8
< date: Thu, 22 Jun 2023 14:37:09 GMT
< connection: close
< transfer-encoding: chunked
< 
[Omitted HTML ;)]

3.b.2 curl --verbose http://127.0.0.1:4200

*   Trying 127.0.0.1:4200...
* Connected to 127.0.0.1 (127.0.0.1) port 4200 (#0)
> GET / HTTP/1.1
> Host: 127.0.0.1:4200
> User-Agent: curl/7.88.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< vary: RSC, Next-Router-State-Tree, Next-Router-Prefetch, Accept-Encoding
< cache-control: no-store, must-revalidate
< x-powered-by: Next.js
< content-type: text/html; charset=utf-8
< date: Thu, 22 Jun 2023 14:39:15 GMT
< connection: close
< transfer-encoding: chunked
< 
[Omitted HTML ;)]

[ak1394]

Thanks for providing the info! It looks like when you start your server on http://localhost:4200 it opens a listening socket at ::1 address which is IPv6 equivalent of 127.0.0.1 (which is a IPv4 address for localhost).

For some reason the extension does not try to connect to ::1 and fails, unlike the curl from the first example which tries 127.0.0.1 unsuccessfully, but connects to ::1 on a second attempt.

I'll look into fixing the extension, and will update the ticket once it's done.

[ak1394]

I've looked into it, and the issue is caused by bad support for hosts with multiple IP addresses in the version of NodeJS that VS Code uses. It should be resolved soon when VS Code upgrades to a newer version of Electron (that has never version of NodeJS) microsoft/vscode#184021

At the same time, maybe it worth looking at the app that your connecting to. When you launch it on localhost it opens listening socket on IPv6 ::1 only, and not on IPv4 127.0.0.1. While it is not strictly wrong, I think it's more common to listen on both addresses so IPv4-only clients can connect to the app.

In any case, I hope that Electron update happens soon and it resolves the issue.

[Frikki]

Thanks a lot, @ak1394

I appreciate your time and effort. I’ll close the issue.