It is generally good idea for this type of cases to get a sniffer trace (in ACE module span 10G backplane interface from supervisor or if ACE appliance take parallel span session of client and server vlan).

This case was investigated in TAC SR and this is a small summary of the traces that may help other users hitting this issue (usually it is good idea to filter by http and client IP) :

This is what we have seen for the non-working scenario.

Packet 1: Client sends HTTP GET to ACE VIP
Packet 2: ACE forwards HTTP GET to RSERVER 
Packet 3: RSERVER answers ACE with HTTP 404
Packet 4: ACE forwards the real server response (HTTP 404) to the client

ACE was not changing anything in the packets that were being loadbalanced. And the HTTP 404 error sent from the server that ACE was forwarding indicates that the Web server thinks that the HTTP data stream sent by the client was correct, but simply can not provide the access to the resource specifief by URL.

Bottom line it was found that in this case the server behaves in a different way based on the hostname used to connect to the application, and this should be addressed on the application/server side. An easy way to check this is by using the server name pointing to the vip in local client hostfile.