Custom Tyk Gateway installation gets connection refused

Hi there.
I’m trying to setup a custom installation (so to say) of Tyk Gateway. This is the dir hierarchy I’ve got:

The Dockerfile:

FROM tykio/tyk-gateway:v2.0

RUN rm -rf /opt/tyk-gateway/apps

The docker-compose:

tyk_gateway:
    build: .
    ports:
      - "8080:8080"
    links:
      - redis
    volumes:
      - ./tyk.conf:/opt/tyk-gateway/tyk.conf
      - ./apps:/opt/tyk-gateway/apps

redis:
    image: redis:latest
    ports:
      - "6379:6379"

The tyk.conf file:

{
  "listen_port": 8080,
  "secret": "<some-secret-that-I-have-hidden-for-the-post>",
  "template_path": "/opt/tyk-gateway/templates",
  "tyk_js_path": "/opt/tyk-gateway/js/tyk.js",
  "use_db_app_configs": false,
  "app_path": "/opt/tyk-gateway/apps",
  "middleware_path": "/opt/tyk-gateway/middleware",
  "storage": {
    "type": "redis",
    "host": "redis",
    "port": 6379,
    "username": "",
    "password": "",
    "database": "2",
    "optimisation_max_idle": 500,
    "optimisation_max_active": 800
  },
  "enable_analytics": false,
  "analytics_config": {
    "type": "csv",
    "csv_dir": "/tmp",
    "mongo_url": "",
    "mongo_db_name": "",
    "mongo_collection": "",
    "purge_delay": -1,
    "ignored_ips": []
  },
  "health_check": {
    "enable_health_checks": true,
    "health_check_value_timeouts": 60
  },
  "optimisations_use_async_session_write": true,
  "allow_master_keys": false,
  "policies": {
  	"policy_source": "file",
  	"policy_record_name": "policies"
    },
  "hash_keys": true,
  "suppress_redis_signal_reload": false,
  "close_connections": true,
  "local_session_cache": {
    "disable_cached_session_state": true
  },
  "uptime_tests": {
    "disable": false,
    "config": {
      "enable_uptime_analytics": false,
      "failure_trigger_sample_size": 3,
      "time_wait": 300,
      "checker_pool_size": 50
    }
  },
  "hostname": "",
  "enable_custom_domains": true,
  "enable_jsvm": true
}

And the auth.json file:

{
  "name": "Authentication API",
  "slug": "auth-api",
  "api_id": "1",
  "org_id": "53ac07777cbb8c2d53000002",
  "use_keyless": true,
  "definition": {
    "location": "header",
    "key": "x-api-version"
  },
  "version_data": {
    "not_versioned": true,
    "versions": {
      "Default": {
        "name": "Default",
        "use_extended_paths": true,
        "extended_paths": {
          "url_rewrites": [
            {
              "path": "hello/asd",
              "method": "POST",
              "match_pattern": "hello/asd",
              "rewrite_to": "hello"
            }
          ]
        }
      }
    }
  },
  "proxy": {
    "preserve_host_header": false,
    "listen_path": "/hello/asd",
    "target_url": "http://localhost:1337/",
    "strip_listen_path": false
  },
  "enable_batch_request_support": false
}

Building and lifting the Gateway works fine. But when I try to hit the URL localhost:8080/hello/asd I get in tyk’s logs:

level=error msg="http: proxy error: dial tcp [::1]:1337: getsockopt: connection refused"

The endpoint on the backend server does not have any authentication at the moment and nothing is logged on it, so I assume the request is not even forwarded from the Gateway.

Any ideas?

1 Like

Hi, where are you running localhost:1337, is it a Docker container as well?

Can you access it directly, using curl?

curl -v http://localhost:1337/

It is not in a docker container. It’s a Sails.js app that I’m running directly on localhost.
And yes, I can directly access it, and I’ve also tested the route to which I want to redirect through the API Gateway.

Can you try using the standard test API as a backend?

http://httpbin.org/

Where? To try to access it via curl or to put it somewhere as configuration?

In the API configuration (proxy block), like:

    "proxy": {
        "listen_path": "/hello/",
        "target_url": "http://httpbin.org",
        "strip_listen_path": true
    }

And then curl your GW IP with /hello/ as path.

Yeah, that works! What was the purpose of this? To try whether the redirecting actually works? What now?

Great, I think that your container can’t access the loopback interface, perhaps you can try setting up a bridge interface, or use the IP address of your host network interface instead.