In an automated test, it's likely APE is started at roughly the same time as the server under test. In that setup, whether the server binds its socket first or APE sends its initial request first depends on how fast the server starts up. If APE is first, it will get a "connection refused" error and it will report the request as failed.
It would be more useful if APE would not give up immediately, but instead wait a bit and then retry. This is how it handles HTTP 503 responses already. However, it currently retries 503 an unlimited number of times, which is a bad idea, since if the 503 is the result of a bug, the test run would never end.
In an automated test, it's likely APE is started at roughly the same time as the server under test. In that setup, whether the server binds its socket first or APE sends its initial request first depends on how fast the server starts up. If APE is first, it will get a "connection refused" error and it will report the request as failed.
It would be more useful if APE would not give up immediately, but instead wait a bit and then retry. This is how it handles HTTP 503 responses already. However, it currently retries 503 an unlimited number of times, which is a bad idea, since if the 503 is the result of a bug, the test run would never end.