The Axis support rep is right:
From the information I have I do not see further that it is something related to the reverse-proxy setup as such, it is rather a client that makes wrong API calls to the Axis device. I am guessing that you use “axis” to identify that the request shall be send to an Axis device to distinguish between your other vendors devices in the network. We are operating a reverse proxy in our lab as well and it works just fine as long as the API’s are honoured.
If the application is not expecting paths to be prefixed with /axis, then you can’t really expect to prefix the path with /axis and expect it to work. Sometimes they are also picky about the Host header of the request, too.
Some applications let you configure a path prefix because they know sometimes people like to do this when reverse proxying, but that that is not a very common feature.
We see this a lot, and I don’t know why people assume they can just change the paths of requests in web applications and expect the applications to still work. We see it so often that @Whitestrake wrote a great wiki article about this:
A reverse proxy simply decodes, then re-encodes, requests between a client and a backend. When you say “obviously direct and has nothing to do with a proxy,” you’re assuming you can tell whether a proxy is being used simply by looking at the URL path. But a URL path doesn’t encode reverse proxy information. The path of a URL and whether a proxy are being used are completely orthogonal concepts (i.e. they have nothing to do with each other).
You can configure a reverse proxy to manipulate the Host or path of a URL (Caddy lets you do this), but this isn’t always enough to make it possible to proxy with a path prefix (see the above linked wiki article).
PS. You can drop reverse_proxy * and just use reverse_proxy. Same thing.