Decide which tool works best for your network debugging problem.
Debugging network problems is challenging because of the fundamental nature of networking. Networking is asynchronous, time-sensitive, and error prone. Moreover, the two programs involved (the client and the server, say) are often created by different developers, who disagree on the exact format of the data being exchanged. Fortunately, a variety of tools can help you debug such problems.
A key goal of these tools is to divide the problem in two. For example, if you’re working on a network client that sends a request to a server and then gets an error back from that server, it’s important to know whether things failed because the request was incorrect (a problem with your client) or because the server is misbehaving. You can use these network debugging tools to view the traffic going over the network, and thus independently check the validity of that traffic.
The best tool to use depends on the APIs you’re using and the type of problems you’ve encountered:
If you’re working at the HTTP level, you may find that your request makes it to the server and then the server sends you a response indicating that it failed in some way (for example, you get an HTTP response with a status code of 500 Internal Server Error). See Debugging HTTP Server-Side Errors.
If you’re using
URLSession, or one of the subsystems that uses
URLSessioninternally, you can enable CFNetwork diagnostic logging to get a detailed view of how your requests were processed. See Debugging HTTPS Problems with CFNetwork Diagnostic Logging.
If you want a low-level view of the traffic exchanged over the network, you need a packet trace. See Recording a Packet Trace.
Some of the most popular network debugging tools, like HTTP debugging proxies, are third-party products. See Taking Advantage of Third-Party Network Debugging Tools.