Are networking abstractions making problems harder to debug?

Think of it as finding the boundary where things stop working, not choosing an abstraction to blame. Compare traffic from the application, the proxy, the node, and another source if you can. A difference between those tests gives you somewhere specific to investigate.

The layers still do useful work. Scheduling and operating a large number of processes by hand would be its own nightmare. The trick is keeping a way to inspect what happens below them.

Keep the basic network tools in your troubleshooting kit. Packet captures with tcpdump and a sustained mtr test can give you clues that tracing at the application layer won't show.

Intermittent loss can take a while to appear, so a quick test isn't always enough. If traffic looks bad beyond the node, the provider may need to investigate its network too.

Don't assume packet loss means an upstream router is broken, either. Drops can happen on the host, including when network buffers fill up. TCP retries can make the symptoms look like slow or unreliable requests rather than an obvious host problem.

A mesh is still a reasonable thing to check, especially if it changes the path requests take. Just don't let familiarity with proxy configuration turn it into the only suspect. Test the other layers before spending the whole afternoon changing mesh settings.