Today I cloned my Tyk Gateway into a new environment. After I modified the conf file to reflect the new IPs, I started testing my API calls and started getting 500 errors. The dashboard shows an error for endpoint //CherwellAPI/token. The correct endpoint is /CherwellAPI/token. For the life of me I can’t determine why this is happening.
It might be the listen path or the target has the additional slash, Tyk tries to remove dupes, but it can’t always find them.
I looked into that issue with no success. I have export and imported from the parent to the clone, also with no success. I have manually tried to recreate it as well.
What version are you running and can you share the api definition?
We are using version 1.9.0.0.
{
“id”: “57e28f324a3a8a0202000003”,
“name”: “Cherwell Test 1”,
“slug”: “cherwell-test-1”,
“api_id”: “ca14b5626b1f48786249cd02291832e6”,
“org_id”: “5671baa7eaf16a05f0000001”,
“use_keyless”: false,
“use_oauth2”: false,
“oauth_meta”: {
“allowed_access_types”: [],
“allowed_authorize_types”: [],
“auth_login_redirect”: “”
},
“auth”: {
“use_param”: false,
“use_cookie”: false,
“auth_header_name”: “TykAuthorization”
},
“use_basic_auth”: false,
“enable_jwt”: false,
“jwt_signing_method”: “”,
“notifications”: {
“shared_secret”: “”,
“oauth_on_keychange_url”: “”
},
“enable_signature_checking”: false,
“hmac_allowed_clock_skew”: -1,
“definition”: {
“location”: “header”,
“key”: “x-api-version”
},
“version_data”: {
“not_versioned”: true,
“versions”: {
“Default”: {
“name”: “Default”,
“expires”: “”,
“paths”: {
“ignored”: [],
“white_list”: [],
“black_list”: []
},
“use_extended_paths”: true,
“extended_paths”: {
“ignored”: [],
“white_list”: [],
“black_list”: [],
“cache”: [],
“transform”: [],
“transform_response”: [],
“transform_headers”: [],
“transform_response_headers”: [],
“hard_timeouts”: [],
“circuit_breakers”: [],
“url_rewrites”: [],
“virtual”: [],
“size_limits”: []
},
“global_headers”: {},
“global_headers_remove”: [],
“global_size_limit”: 0
}
}
},
“uptime_tests”: {
“check_list”: [],
“config”: {
“expire_utime_after”: 0,
“service_discovery”: {
“use_discovery_service”: false,
“query_endpoint”: “”,
“use_nested_query”: false,
“parent_data_path”: “”,
“data_path”: “”,
“port_data_path”: “”,
“use_target_list”: false,
“cache_timeout”: 60,
“endpoint_returns_list”: false
},
“recheck_wait”: 0
}
},
“proxy”: {
“listen_path”: “/cherwell-test-1/”,
“target_url”: “http://xxx.xxx.xxx.xxx/CherwellAPI/”,
“strip_listen_path”: true,
“enable_load_balancing”: false,
“target_list”: [],
“check_host_against_uptime_tests”: false,
“service_discovery”: {
“use_discovery_service”: false,
“query_endpoint”: “”,
“use_nested_query”: false,
“parent_data_path”: “”,
“data_path”: “hostname”,
“port_data_path”: “port”,
“use_target_list”: false,
“cache_timeout”: 60,
“endpoint_returns_list”: false
}
},
“custom_middleware”: {
“pre”: [],
“post”: [],
“response”: []
},
“cache_options”: {
“cache_timeout”: 60,
“enable_cache”: true,
“cache_all_safe_requests”: false,
“enable_upstream_cache_control”: false
},
“session_lifetime”: 0,
“active”: true,
“auth_provider”: {
“name”: “”,
“storage_engine”: “”,
“meta”: {}
},
“session_provider”: {
“name”: “”,
“storage_engine”: “”,
“meta”: null
},
“event_handlers”: {
“events”: {}
},
“enable_batch_request_support”: false,
“enable_ip_whitelisting”: false,
“allowed_ips”: [],
“dont_set_quota_on_create”: false,
“expire_analytics_after”: 0,
“response_processors”: [],
“CORS”: {
“enable”: false,
“allowed_origins”: [],
“allowed_methods”: [],
“allowed_headers”: [],
“exposed_headers”: [],
“allow_credentials”: false,
“max_age”: 24,
“options_passthrough”: false,
“debug”: false
},
“domain”: “”,
“do_not_track”: false,
“tags”: []
}indent preformatted text by 4 spaces
With v1.9 there was a bug in reporting the path correctly in the analytics, but it wasn’t the cause of the errors themselves, just reporting the path incorrectly.
To check it - make a request to the API and check the returned headers - if you see any related to rate limits, then the request has proxied correctly and returned, so the 500 error is upstream.
Also you can see if the gateway output logs show any issues.
The log is showing an “i/o timeout” for each failed call.
My issue has been resolved. After reviewing the log, I saw timeout errors on port 80. It was found that there was not an open route between the source and destination over port 80.
Thanks for the help.
1 Like