Fiddler listens to outbound requests rather than inbound requests so you're not going to be able to monitor all the requests coming in to your service by using Fiddler.
The best you're going to get with Fiddler is the ability to see all of the requests as they are generated by your Console App (assuming that the app generates web requests rather than using some other pipeline).
If you want a tool that is more powerful (but more difficult to use) that will allow you to monitor ALL incoming requests, you should check out WireShark.
This is straightforward if you have control over the client that is sending the communications. All you need to do is set the HttpProxy on the client-side service class.
I did this, for example, to trace a web service client running on a smartphone. I set the proxy on that client-side connection to the IP/port of Fiddler, which was running on a PC on the network. The smartphone app then sent all of its outgoing communication to the web service, through Fiddler.
This worked perfectly.
If your client is a WCF client, then see this Q&A for how to set the proxy.
Even if you don't have the ability to modify the code of the client-side app, you may be able to set the proxy administratively, depending on the webservices stack your client uses.
When .NET makes a request (through a service client or HttpWebRequest, etc) it will always bypass the Fiddler proxy for URLs containing localhost, so you must use an alias like the machine name or make up something in your 'hosts' file (which is why something like localhost.fiddler or http://HOSTNAME works)
If you specify the proxyaddress, you must remove it from your config if Fiddler isn't on, or any requests your app makes will throw an exception like:
No connection could be made because the target machine actively refused it 127.0.0.1:8888
If for some reason you are unable to get Fiddler to work, or would rather log the requests another way, another option is to use the standard WCF tracing functionality. This will produce a file that has a nice viewer.
Use fiddler a Reverse Proxy is the final solution for me.
First, configure fiddler as reverse proxy with REGDIT, like the doc said: https://docs.telerik.com/fiddler/configure-fiddler/tasks/usefiddlerasreverseproxy#configure-fiddler-as-reverse-proxy
1)Click Tools > Fiddler Options. Ensure Allow remote clients to connect is checked
2)Create a new DWORD named ReverseProxyForPort inside HKEY_CURRENT_USER\SOFTWARE\Microsoft\Fiddler2.
3)Set the DWORD to the local port where Fiddler will re-route inbound traffic.
4)Restart Fiddler.
Second, change the client to call service through proxy
for example , here is my client app.config:
WeatherForecastServiceClient client = new WeatherForecastServiceClient("BasicHttpBinding_IWeatherForecastService", "http://localhost:8888/WeatherForecastService.svc");
var data = client.GetData(1000);
client.Close();