You don't.
I assume that your domains are protected by HTTPS and that the Nginx Proxy Manager terminates the TLS traffic. Thus, the internal sites will most probably be HTTP without TLS. You would have to use HTTP for the IP-based local access, which many browsers refuse to do these days.
Even if this was possible, many websites create internal links with a full URL, so knowing they are xxx.mydomain.com, they will generate such links as well when you use them as http://192.168.x.x, leading to problems on the first click and also for references to stylesheets and other ressources.
And if you created a DNS alias to point xxx.mydomain.com to 192.168.x.x when you access that site from your LAN, then you would connect directly to the web service, without the reverse proxy, so you would not get presented the (correct) certificate, if the real web service can talk HTTPS at all.
As you can see, NPM is not even involved once you directly contact the web service at 192.168.x.x.
It would not work either, if you instead used the IP of the NPM manager instead, because it would have to present a valid TLS certificate for 192.168.x.x - which would have to be created using an internal CA and imported to the browser's trust store. Even if it did, the problem of internal links may persist.
What some people do is to create a DNS alias for xxx.mydomain.com for the internal IP of the NPM manager in order to avoid having do to NAT hairpinning to access the WAN IP. That of course works.
I assume that your domains are protected by HTTPS and that the Nginx Proxy Manager terminates the TLS traffic. Thus, the internal sites will most probably be HTTP without TLS. You would have to use HTTP for the IP-based local access, which many browsers refuse to do these days.
Even if this was possible, many websites create internal links with a full URL, so knowing they are xxx.mydomain.com, they will generate such links as well when you use them as http://192.168.x.x, leading to problems on the first click and also for references to stylesheets and other ressources.
And if you created a DNS alias to point xxx.mydomain.com to 192.168.x.x when you access that site from your LAN, then you would connect directly to the web service, without the reverse proxy, so you would not get presented the (correct) certificate, if the real web service can talk HTTPS at all.
As you can see, NPM is not even involved once you directly contact the web service at 192.168.x.x.
It would not work either, if you instead used the IP of the NPM manager instead, because it would have to present a valid TLS certificate for 192.168.x.x - which would have to be created using an internal CA and imported to the browser's trust store. Even if it did, the problem of internal links may persist.
What some people do is to create a DNS alias for xxx.mydomain.com for the internal IP of the NPM manager in order to avoid having do to NAT hairpinning to access the WAN IP. That of course works.
"