CGI-Executables redirected because of error

The specified CGI file that's being served to the clients contains a reference to a CGI file that doesn't exist, and it further appears that the error page itself doesn't exist. That's what the HTTP 404 status is reporting.

Start by flushing the browser caches on the clients, then by verifying the various references in the HTML are to valid links; either to actual files or to whatever software is vending out the CGI files in response to the HTTP page requests.

The Apache logs will report the arriving URLs and the associated HTTP status requests — 200 for success, 404 for missing pages or errant references — and a variety of other errors depending on how the particular web site is implemented and what the associated HTML and web code is doing.

Basically, there's a coding bug somewhere in the web site HTML, or the file really is missing from the specified location.

Was this web site working before? If so, then the changes that were made would probably be good initial suspects for what's gone wrong...

I'm not at all sure what's going on here, nor details of the configuration or the error itself.

If the following discussion fails to identify a trigger, then I'd suggest creating a small HTML file with a reference over to the CGI script (or to a stub CGI script), and verify that the test web page loads and that the CGI is triggered. Create yourself a test case or reproducer in other works, and particularly something that can be posted here if you can't figure out what's wrong with the HTML code or the CGI access. (That is, if this is being triggered by the tags in the HTML: if there's an explicit domain specification in the HTML code that's not correct or not working.)

You've pointed at two domains that can be in a URL on the browser; the IP address and localhost, but not at what is listed in the referencing tag in the HTML itself. That domain in that tag would either be a URL with the domain name omitted (which would use the current domain) or there'd be an explicit reference to the target host; the DNS name of the local host, if the box is serving the page. This would imply that the HTML references do not include an explicit domain name.

If your gateway-firewall-router-NAT box isn't able to reflect internal references to the public static IP back in through NAT, then references to the public static IP address will fail. That can be worked around with various approaches including a local DNS definition for the domain in the local DNS services (basically configuring the local DNS server to respond authoritatively for the domain) that provides the internal address as the translation and not allowing the connection to reach the external DNS server and the external IP name), or an upgrade to a gateway-firewall-router-NAT box that can "reflect" traffic back in through NAT, or removing the host name from the HTML tags and allowing the web server to default the references to "self".

As a general test given this is OS X Server and thus can be subject to weirdness due to DNS errors (though I'd guess that this case is something within the HTML code of the web page), also launch Terminal.app from Applications > Utilities and issue the following diagnostic command to verify DNS is correct and functioning:

sudo changeip -checkhostname

Confirm that the name is what is expected, and that the command indicates no changes are required. If the tag(s) in the HTML are referencing some other server, then the references won't resolve.