Connection refused on address that Docker uses to talk to the host machine

I am trying to hit a SailsJS app, that is running on my localhost at port 1337.
I am not sure whether is the correct host, so that the gateway container can talk to the host machine?

This is the .json file of my gateway configuration:

  "version_data": {
    "not_versioned": true,
    "versions": {
      "Default": {
        "name": "Default",
        "use_extended_paths": true,
        "extended_paths": {
          "url_rewrites": [
              "path": "test/asd",
              "method": "GET",
              "match_pattern": "test/asd",
              "rewrite_to": "test"
  "proxy": {
    "preserve_host_header": false,
    "listen_path": "/test/asd",
    "target_url": "",
    "strip_listen_path": false
  "enable_batch_request_support": false

In the logs of the gateway I can see the gateway is hit, but does not redirect:

I believe the problem is in telling the gateway the correct host/IP, but I am not sure how to find that out.

I ran /sbin/ip route|awk '/default/ { print $3 }' inside the container to find out the IP that Docker for Mac uses to talk to the host machine is Now, I replaced that in the .json file, so now it’s:

    "target_url": ""

But I get http: proxy error: dial tcp getsockopt: connection refused" error.

Erm, in docker, I’d look at giving your service a hostname since docker tends to dynamically assign IPs

It will also need to be visible (pingable) from inside the container - there isn’t a problem with Tyk here, there is a problem with your docker networking.

But I’m running the server (the Sails app) directly on localhost, not inside a container.

There’s an easy check here: open a bash shell inside the docker container and try to ping that IP.

All Tyk is doing here is going to the TCP stack in the OS to open a connection to the IP and it’s getting timed out, that is a low-level error - which implies a networking problem. Since docker sets up it’s own internal network for the container services, there’s no guarantee it can actually access the host’s subnet without a bridge.

Looks like this has been a problem for a while (there’s an open issue from 2013!), and there’s a way to add the route in:

Okay, I found out the problem - it’s the way Docker for Mac (which is different from Docker Toolbox) is implemented (the Docker guys have restrictions because of how networking in OSX is implemented…). This is the solution.