There are a couple issues going on here.
First, your web server needs to be listening on the address that sandbox can reach (it probably isn't by default).
Second, your firewall on the server needs to allow inbound connections from the address space that sandbox uses.
Changing the IP address binding of your webserver varies by the server platform. If this were a .net project using Kestrel or IIS, you might check in your project's properties folder for a file named "launchSettings.json", and you'll note that by default the addresses the server(s) listens on is "localhost". That's ordinarily fine, but if you're trying to hit it from sandbox, you'll need to be listening on the address that the sandbox can reach.
Your config probably says something like "https://localhost:4200". Most servers are going to be just fine with you telling it to listen on 0.0.0.0, which means any address, so change the entry to "https://0.0.0.0:4200". You can just put this into launchSettings.json to get it working, but likely you'd want to keep this pretty restricted long term. In this case, you can add the specific host address used by the virtual switch.
To get that address, as described in another answer, you get the ip address of the host that your sandbox can reach either by looking on the host with ipconfig to find the address of the adapter named "Ethernet adapter vEthernet (Default Switch)" or look at the gateway address on the sandbox under ipconfig. Same/Same.
You want your server to be listening on that address, by default it's probably not.
Now you should be able to browse to that host address from the host itself and it should reply just fine. NOTE that you'll probably get a certificate error, though, but at least you know the server is listening.
Now try hitting that same address from the sandbox. If you can't hit it from the sandbox, it's just a firewall issue at this point. As always, there are a few ways to address this problem from simple and insecure to more complex and more secure:
Temporarily disable the firewall on the host.
Open Windows Security, click on Firewall & Network Protection, then "Allow an app through firewall", find the pre-existing entry for the app you're running, and open it to public networks. NOTE that this may not be very 'sticky' as the app entry can change over time.
Open Advanced Settings under Firewall & Network Protection. Create a new rule, maybe do it by port and specify the port (4200) that your server is listening on. You can loosen or tighten this to your heart's content with all sorts of other parameters. The idea is that you want to spend as little time worrying about whether this rule is working (open enough), but not worry about somebody on the LAN hitting your system (closed enough). Experiment until you find the right restriction level that you're comfortable with.
As mentioned, some behaviors will now change. The certificate error is one. If you're testing something that is configured to use an external identity provider, you'll also need to consider that your endpoint has changed from "localhost" to the address in question. But if you're getting errors from that sort of thing, you've already solved your networking issues.