Historian Web Client behind a reverse proxy

It will depend on what exactly you're trying to do and the limitations in your architecture, but also consider simply forwarding a port instead of using a reverse proxy. 

If the Historian server "MyHist" is behind a NAT firewall using the default port of 32569 for the web site and the client side of the firewall has an IP address of "10.0.0.50", you should be able to forward a port (e.g. 8069) from the firewall to the web site and then have a browser access "10.0.0.50:8069". With DNS/host entries, you can use a name instead of the IP address.  

If you need a path (not just a port) such as “http://myhist/hcweb” to act as a proxy for “http://myhist:32569”, then you do need to use a reverse proxy, but it will need to be one that supports "rewriting" URLs from the site, such as NGINX's "rewrite" directive. That way the proxy will intercept the URLs within the returned HTML and "rewrite" them to be appropriate for the proxy client. 

If you're using the HTTPS with the site, you'll have to do more to get the certificate created to work correctly (or, have the browser ignore certificate errors, which compromises the value of using HTTPS). 

Both of the options above are valid for a demo scenario, but I would not recommend them for a production environment from a cybersecurity perspective: if there were a remotely-exploitable vulnerability in the web site, it is likely that both approaches would expose that vulnerability. Instead, it is preferrable to block all outside access to the web site and replicate data from that Historian to another system that is accessible from the client network (e.g. another AVEVA Historian, an AVEVA PI, CONNECT or AVEVA Insight).

It will depend on what exactly you're trying to do and the limitations in your architecture, but also consider simply forwarding a port instead of using a reverse proxy. 

If the Historian server "MyHist" is behind a NAT firewall using the default port of 32569 for the web site and the client side of the firewall has an IP address of "10.0.0.50", you should be able to forward a port (e.g. 8069) from the firewall to the web site and then have a browser access "10.0.0.50:8069". With DNS/host entries, you can use a name instead of the IP address.  

If you need a path (not just a port) such as “http://myhist/hcweb” to act as a proxy for “http://myhist:32569”, then you do need to use a reverse proxy, but it will need to be one that supports "rewriting" URLs from the site, such as NGINX's "rewrite" directive. That way the proxy will intercept the URLs within the returned HTML and "rewrite" them to be appropriate for the proxy client. 

If you're using the HTTPS with the site, you'll have to do more to get the certificate created to work correctly (or, have the browser ignore certificate errors, which compromises the value of using HTTPS). 

Both of the options above are valid for a demo scenario, but I would not recommend them for a production environment from a cybersecurity perspective: if there were a remotely-exploitable vulnerability in the web site, it is likely that both approaches would expose that vulnerability. Instead, it is preferrable to block all outside access to the web site and replicate data from that Historian to another system that is accessible from the client network (e.g. another AVEVA Historian, an AVEVA PI, CONNECT or AVEVA Insight).