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.
Problem routing to
In the Gateway Audit Events, on the Associated Logs tab, check for event "problem routing to". When "problem routing to" is caught in the Associated Log, this means the request made it through all of the API Gateway policies, but there was a problem routing the request to the URL in the "problem routing to" dialog box. If the URL is external (outside your network), you will need to contact the vendor to determine why requests cannot route to their URL.
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.
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.
If there is an issue with the URL being used to route the requests to the backend application or service, events will not be written to the application server logs, such as SystemOut.log (WebSphere), catalina.log (Tomcat), or mule_ee.log (Mule), as the API Gateway is not able to establish a connection to the application server.
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.