Try analyzing connections with traceroute (tracert on windows) and tcpdump/wireshark from testing with your laptop.
I was thinking about how could you be getting different results with wireguard when on lan vs the internet. Here are some thoughts:
When your laptop is on the lan but is connected to your wg service, it still has a route for 192.168.1.0/24 via 192.168.1.1 and uses that to connect to your home web server.
When your laptop is on the internet and connected to your wg service, the wg vpn is the active route to 192.168.1.0/24.
Try setting your local dns server (192.168.1.1) for your local web services to point to the real web server (192.168.1.4?) if it isn't or add an entry to the hosts file on your laptop pointing to the web server real ip. and test connectivity. If 192.168.1.4 is the web server, try pointing your browser to https://192.168.1.4/ and see if it connects there, even if it then does a browser redirect. (Browser dev tools and/or packet capture can be useful here)
Without reasons to make it more complicated, I'd set things up so lan clients and wg clients name resolve and connect directly to the local web server and clients on the internet without wg resolve via ddns to the router wan ip and make use for the firewall redirects/port forwards. If this is what you think is in place now then packet captures might show more of what is going on. Logging and debugging options on the firewall might help as well.
To test my idea about the laptop on the lan with wg active, maybe netstat -rn would show what routes are in place and active.