Error 601 typically means there is some problem routing a request to another system. If this is happening with multiple API Gateway services, this suggest a network issue.

Routing issue

In the Gateway Audit Events, on the Associated Logs tab, check for event "problem routing" or "routing failed" or "unable to route". This means the request made it through all of the API Gateway policies, but there was a problem routing the request to the backend service. If the backend service is external (outside your network), you will need to contact the vendor to determine why requests cannot route to their URL.

Sometimes, Downstream service returned status (404) will be captured. This means the request made it to the backend service but the resource being requested is Not Found. 404 means not found. For example, if the backend service is http://www.example.com/foo and "foo" does not exist, this can return 404 Not Found. If routing to a service inside your network, consult with the owner of the service the request is being routed to to determine why 404 Not Found is being returned. If the backend service is external (outside your network), you will need to contact the vendor to determine why requests cannot route to their URL.

Server cert found but not trusted for SSL

If the following is being captured, you might need to add the certificate to "Manage Certificates" in the API Gateway and set the certificate usage to "SSL". In this example, you would add the foo.example.com certificate to Manage Certificates in the API Gateway, with the usage set to "SSL".

Problem routing to https://apig.example.com/foo. 
Error msg: Unable to obtain HTTP response from https://apig.example.com/foo
Server cert cn=foo.example.com,ou=information technology,o=Acme,l=appleton,st=wi,c=us found but not trusted for SSL.

Read timed out

Read timed out means that the backend service is not responding in a timely manner. Check the backend service for errors in the logs.

Connection refused

If you see “Connection Refused”, there may be some issue with the URL being used to route the request to the backend application or service. For example, let’s say requests are being routed to http://example.com:12345/enterprise/sample.

• Protocol: The protocol may need to be HTTP or HTTPS. 
• Hostname: Using nslookup, ensure the host name can be resolved to an IP address. Also ensure that the application or service exists on the server that the host name resolves to.
• Port: The port will need to be open on the target server - this usually means checking the web or application server the request is being routed to.
• Context root: The context root, such as /enterprise/sample, does not always need to match the context root of the service. The developer should be able to provide you with the valid context root.

Be aware that in this scenario, events may or may not not be written to the backend system logs.

If the backend system log contains DNS resolution failed events, you will probably need to consult with the DNS system administrators for the backend system (not the API Gateway).

Connection reset

If you see “Connection Reset”, there may be an issue with the TLS protocol being used in the "route via HTTP fragment". If the client is using a different TLS version than what is defined in the route via HTTP fragment, this can result in Connection Reset.

The ideal solution is to set TLS Version to "Any" so that the client and API Gateway negotiate the TLS version.