Got: RequestError: connect ECONNREFUSED 127.0.0.1:443

[franleplant]

Describe the bug

• Node.js version: 14
• OS & version: docker/alpine

Using this library through https://github.com/panva/node-openid-client , when making the initial request of the open id connect discovery document it throws this weird error

Actual behavior

2020-12-28T21:49:39.282Z tenx:lib-auth:http >>> Request GET https://private-oidc-provider.com//.well-known/oauth-authorization-server
2020-12-28T21:49:39.282Z tenx:lib-auth:http Headers: {
  'user-agent': 'openid-client', // the one that we use works
  accept: 'application/json',
  'accept-encoding': 'gzip, deflate, br'
}
2020-12-28T21:49:39.282Z tenx:lib-auth:http Body undefined
2020-12-28T21:49:39.283Z tenx:lib-auth:http >>> Request GET https://private-oidc-provider.com/.well-known/openid-configuration
2020-12-28T21:49:39.283Z tenx:lib-auth:http Headers: {
   'user-agent': 'openid-client',// the one that we use works
  accept: 'application/json',
  'accept-encoding': 'gzip, deflate, br'
}
2020-12-28T21:49:39.283Z tenx:lib-auth:http Body undefined
2020-12-28T21:49:39.297Z tenx:lib-auth:init Error creating costar client AggregateError:
    RequestError: connect ECONNREFUSED 127.0.0.1:443
        at ClientRequest.<anonymous> (/usr/src/app/node_modules/got/dist/source/core/index.js:957:25)
        at /usr/src/app/node_modules/dd-trace/packages/dd-trace/src/scope/base.js:68:19
        at Scope._activate (/usr/src/app/node_modules/dd-trace/packages/dd-trace/src/scope/base.js:44:14)
        at Scope.activate (/usr/src/app/node_modules/dd-trace/packages/dd-trace/src/scope/base.js:13:17)
        at ClientRequest.<anonymous> (/usr/src/app/node_modules/dd-trace/packages/dd-trace/src/scope/base.js:67:20)
        at ClientRequest.req.emit (/usr/src/app/node_modules/dd-trace/packages/datadog-plugin-http/src/client.js:93:21)
        at ClientRequest.origin.emit (/usr/src/app/node_modules/@szmarczak/http-timer/dist/source/index.js:39:20)
    RequestError: connect ECONNREFUSED 127.0.0.1:443
        at ClientRequest.<anonymous> (/usr/src/app/node_modules/got/dist/source/core/index.js:957:25)
        at /usr/src/app/node_modules/dd-trace/packages/dd-trace/src/scope/base.js:68:19
        at Scope._activate (/usr/src/app/node_modules/dd-trace/packages/dd-trace/src/scope/base.js:44:14)
        at Scope.activate (/usr/src/app/node_modules/dd-trace/packages/dd-trace/src/scope/base.js:13:17)
        at ClientRequest.<anonymous> (/usr/src/app/node_modules/dd-trace/packages/dd-trace/src/scope/base.js:67:20)
        at ClientRequest.req.emit (/usr/src/app/node_modules/dd-trace/packages/datadog-plugin-http/src/client.js:93:21)
        at ClientRequest.origin.emit (/usr/src/app/node_modules/@szmarczak/http-timer/dist/source/index.js:39:20)
    at maybeSettle (/usr/src/app/node_modules/p-some/index.js:31:11)
    at /usr/src/app/node_modules/p-some/index.js:69:23
    at processTicksAndRejections (internal/process/task_queues.js:93:5)

Expected behavior

This request to work.

This request works

• running the code locally on a lot of developer machines
• works via curl/wget from inside the Kube cluster node and pods

But it doesn't work via node-oidc-client and got when running side the pod / container.

Code to reproduce

working on it, but it is hard because it only fails inside the container inside the pod inside the kube cluster

Checklist

• [ x ] I have read the documentation.
• [ x ] I have tried my code with the latest version of Node.js and Got.

[sindresorhus]

Then I would look into what the difference is between the dev machine and the container. For example, maybe the container is behind a proxy, which would require extra set up in Got. I would recommend doing some more digging on your own. There's not much we can do with the information you have provided unless you can provide a reproducible test case.

[franleplant]

That’s actually a good clue to start looking at, I acknowledge Im not
providing all the necessary information and I thank you for replying so
quickly. I will report back whenever I get any news.

Would you be interested in paid time helping my company solve this issue?

Fran

On Mon, 28 Dec 2020 at 23:59 Sindre Sorhus [e-mail] wrote:

Then I would look into what the difference is between the dev machine and
the container. For example, maybe the container is behind a proxy, which
would require extra set up in Got. I would recommend doing some more
digging on your own. There's not much we can do with the information you
have provided unless you can provide a reproducible test case.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/sindresorhus/got/issues/1572#issuecomment-751928953,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAOEIJ2SRPSMSN2MDPTEA6LSXFAXLANCNFSM4VMSHIBA
.

[franleplant]

Does the fact that the connection that fails is 127.0.0.1 ring any bells to
you? Why is that connection failing when Im trying to get to a completely
different domain that resolves to other ip?

On Tue, 29 Dec 2020 at 00:09 Francisco Guijarro [e-mail]
wrote:

That’s actually a good clue to start looking at, I acknowledge Im not
providing all the necessary information and I thank you for replying so
quickly. I will report back whenever I get any news.

Would you be interested in paid time helping my company solve this issue?

Fran

On Mon, 28 Dec 2020 at 23:59 Sindre Sorhus [e-mail]
wrote:

Then I would look into what the difference is between the dev machine and
the container. For example, maybe the container is behind a proxy, which
would require extra set up in Got. I would recommend doing some more
digging on your own. There's not much we can do with the information you
have provided unless you can provide a reproducible test case.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/sindresorhus/got/issues/1572#issuecomment-751928953,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAOEIJ2SRPSMSN2MDPTEA6LSXFAXLANCNFSM4VMSHIBA
.

[Giotino]

I see some dd-trace between where the request is made and where it fails.

I think that Datadog may be patching the default request agent (or function) like in this case: https://github.com/sindresorhus/got/issues/1515#issuecomment-717983611

[szmarczak]

I'd check if the http.request function has been patched or not. I'm pretty sure it is.

[franleplant]

Ok, thanks to all the helped me, effectively it was kinda the same of all the previous related issues: other libraries changing the global Node.js http /https clients. As a minor take away: we, as the js community, need to do somethings different.

What libraries were impacting?

I made two changes and those fix the issue, not sure exactly which one of them:

• removed @sentry/node (it was an old version) that depends on the problematic family of http[s]-agent-proxy and agent-base
• upgraded the datadog client dd-trace to the latest version (0.29.1 at time of writing, we were pretty far behind on that).

Can't say much more about it but:

• try to identify which of the libraries in your dep tree might be messing around with the global http / https clients of Node.js
• remove or update them

There's no easy method for this, I just wen to my yarn.lock and search for keywords such as http, request, etc.

I hope this helps others in the future.

Thanks a lot @sindresorhus @szmarczak @Giotino for your help and sorry for the trouble, this was entirely not a bug in Got.

Fran

[nero120]

@franleplant I hit this exact issue yesterday. I upgraded openid-client from 3.15.10 to 4.2.2 and found that where I import the package symphony-api-client-node it started causing openid-client to start puking out those ECONNREFUSED 127.0.0.1:443 errors. If I commented out the symphony-api-client-node import then the errors disappeared. If I downgraded openid-client back to 3.15.10 the errors disappeared.

I figured it was due to [email protected] upgrading got from 9.x to 11.x, and found your issue here. Looks like symphony-api-client-node has a dependency of https-proxy-agent which coincides with what you mentioned above. Thanks for the info!