That's a good question. You have two parts to ANTS Load: the script recorder and the script runner. The script recorder will pick up any requests during the recording session through a built-in proxy. Theoretically this means it will pick up the request made by the browser as the result of an HTTP 301 or 302 request.
The script player does not support redirects, which confuses users who assume ANTS Load will behave like IE or .NET's HTTPRequest and automatically follow the redirect. But that behavior would be redundant as the URL should already appear in the script.
There are reasons why this approach falls apart. One is that if the redirection URL is dynamically generated on the server, the GET request that simulates the redirect could have the wrong URL or QueryString in it. For example, if the redirect location has a querystring in it containing a GUID or a sessionID, the redirection request in the test script could contain QueryString variables for a previous session. Also, if stateinformation is used in the POST method so that the information being sent to the server is different for each virtual client, the redirection URL recorded in the test script could also be invalid. In these cases you need to handle the redirections programatically in the script.
I am aware that on certain occasions, the GET request generated as the result of a redirect isn't picked up. I don't have a clear answer on this. I suppose the bottom line is that the request to follow 'redirect' was not correctly handled by the web browser. All requests sent by the web browser client should be trapped by the ANTS Load script recorder's proxy. Maybe your 'redirect' isn't a redirect at all (HTTP 301, 302), but a direct write to the client using the response stream on the server.
Hopefully this clears things up a bit.