Recently in getting public development, in addition to actively to adjust the public interface, there is also a public backend to adjust your situation in turn, between the attack and conversion of a line. In the case of callbacks, it is necessary to want to know how the other side came to the request. I've used Fiddler a lot previously to grab requests going out from this machine, and it works very well, so now I'm wondering if I can reverse the process and have it grab incoming requests. Doing a search, the answer is yes, and there is documentation on the official website saying this.
This article is actually based on the instructions in the above document.
As you can see from the title of the documentation, the principle of implementing anti-catch is essentially configuring Fiddler as a reverse proxy service (Reverse Proxy). About the reverse proxy is how a thing please readers to understand their own, this article will not repeat, simple understanding is to let the real provide services of the site to hide behind the proxy service, the request is first to the proxy, and then by the proxy forwarded to the site behind, and then the site's response back out. Based on this principle, of course Fiddler, acting as a proxy, gets the round-trip data.
The documentation says three approaches to configuring reverse proxies, but there's really no difference in the way the last two are done, it's just a matter of choosing who uses the port ~ which will be covered below, so there are really only two approaches.
I. Registry specified port method (not recommended, has disadvantages)
1, in HKEY_CURRENT_USERSOFTWAREMicrosoftFiddler2 under the new DWORD-type key value ReverseProxyForPort, decimal way to enter the port of the site to capture the packet, such as the site port is 80, get done as shown in Figure.