Level=error msg=http: proxy error: dial tcp <some IP>:80: connect: connection refused

I am setting up tyk open source gateway locally using helm and every things worked correctly until I tried to create a custom api and connect to it
I am using this api

{
  "name": "Keyless-HttpBin",
  "api_id": "1",
  "org_id": "default",
  "use_keyless": true,
  "auth": {
    "auth_header_name": ""
  },
  "version_data": {
    "not_versioned": true,
    "versions": {
      "Default": {
        "name": "Default",
        "expires": "3000-01-02 15:04",
        "use_extended_paths": true,
        "extended_paths": {
          "ignored": [],
          "white_list": [],
          "black_list": []
        }
      }
    }
  },
  "proxy": {
    "listen_path": "/httpbin/",
    "target_url": "http://httpbin.org",
    "strip_listen_path": true
  },
  "active": true
}

this is the error I get from viewing the logs of the Tyk-gateway

and The result of the health check on the gateway give me

{
    "status": "pass",
    "version": "5.2.3",
    "description": "Tyk GW",
    "details": {
        "redis": {
            "status": "pass",
            "componentType": "datastore",
            "time": "2024-03-25T13:36:54Z"
        }
    }
}

Please help me to fix this issue.

Just to be clear I had used the Quick start tutorial for tyk-oss deployment in helm

"http: proxy error: dial tcp ... connect: connection resued"

The error shown looks like a proxy error but your target_url looks to be pointing to httpbin.org. The error typically means that the gateway can’t reach the upstream host. Maybe you could ping the IP and port from the container running Tyk?

When I import your API definition, everything works as expected.

How did you reach the liveness endpoint on /hello? Was it through the IP?

Also, is the IP public or private?

Ok I used the forward port command to use my localhost as shown in this tutorial made by me GitHub - Harasisco/tyk-API-Gateway I then entered the postman and checked the liveness endpoint using Get method to http://localhost:8080/hello

For the IP its a public IP and This is the message I get each time

I think you may want to troubleshoot by process of elimination. You could try the following:

  • Test with a well-known public hostname
  • Test with the IP of the well-known hostname
  • Test with your custom hostname if you have one. If not test with the IP
  • Test the custom hostname or IP without Tyk proxy
  • Check if you have any firewall, blocker or some other kind of proxy intercepting the request.
  • Does the target upstream have logs you could confirm from?

From what I can sense, the gateway simply can’t reach the target upstream. If a well known-public hostname doesn’t work, then you may want to check your egress or outbound network connections

The problem that I tried with multiple APIs and each one give the same error with the same public IP

Multiple APIs won’t make a difference since they originate from the same host. I suspect something is blocking the connection from the gateway. If not the error should have been more of a timeout rather than a connection refused.

I think the focus should be on whether it is an egress network error from the container (k8 setup) or an ingress network error from the upstream. If it’s only happening with your custom IP then the issue is probably the latter.

How to check this IP for which service?

I’m not sure I understand the question. Could you elaborate more?

Also, have you confirmed if the issue is only happening with your custom IP or other public IP/hostnames as well e.g. httpbin.org?

the public IP in the problem it seams to be a weird IP for barefruit ISP I really don’t know what is this and why it is configured in my ubuntu machine

I am still facing the same error

for more info I found that when I am using options instead of a local values.yaml the error disappear, but why?

Did you mean the public IP is the problem? Can you share the public IP?

I don’t understand what options mean. Could you elaborate more on this?

Sorry for bothering you sir but finally I solved the problem

That’s great news! Can you share what the issue was?

I suspected it was a networking issue within your local network. If your target URL is still httpbin.org and unchanged, then we could replicate the error shared if we perform the following steps:

  • import your API definition
  • setup a local httpbin.org server
  • map your local IP to httpbin.org
  • shutdown the local httpbin server
  • then try the request using the gateway

Is this the case or was is something completely different?

The problem was in the vmware network settings. It was NAT and I had to change it to bridge to stop the conflict.