Monitor all requests and responses originating from XAMPP’s apache server

apache-2.4trafficxampp

I am using Windows 10 and XAMPP to do local php development. I need to capture traffic originating from the apache server XAMPP uses but I can't figure out how. I'm using Fiddler and I can see my browser's requests to localhost but that's it.

Let's say I am loading a local php page, localhost/displaystuff.php, that uses curl to send off 10 different requests to 10 different hosts, then gets 10 different responses, sorts & displays those results. That's obviously coming from apache/XAMPP but none of it is visible to Fiddler (or I don't know how to make it visible), and to my knowledge there are no logs that display that information.

I need to see that traffic essentially like you would see it in the network tab of Chrome Devtools in the browser, each request with headers, body, timing information, etc along with the response provided to that request.

Can someone tell me where that information is logged (if it is), or give me a step by step method to capture / monitor it in realtime?

XAMPP 7.3.1 with Apache/2.4.37

Best Answer

You can check the log in Xampp->apache->logs->access.log file . Open your accees.log file in any code editor or notepad then you see the realtime log.

Related Solutions

Linux – Weird 302 response from apache server

You asked for "directions" so... here are mine.

In your two transcripts I saw, in the first one, this:

[...]
Server: Apache
[...]

and in the second one, this:

[...]
Server: Apache/2.4.6 (CentOS) PHP/5.6.24
[...]

Even tough those are two different HTTP response (302 Found the first; 200 OK the second), I bet that those two responses are coming from different web servers. So let's try to investigate such an hypothesis...

As a first step, as already mentioned in the @HBruijn comments, we need to ensure that both HTTP clients are opening the HTTP connection towards the same HTTP server. On each of them, please, run:

ping service-name.domain.tld

and ensure that in the output you're seeing the same IP address. If not, let's stop here and... is up to you to step forward on a different issue :-)

If both ping resolve to the same IP address, than the troubleshooting process is really different, based on the "relative" location of the three hosts: are "Client A" and "Client B" connected to the same Ethernet LAN/segment? is "Server C" connected to the same Ethernet LAN/segment?

If the three machines are connected to the same LAN, than something to check could be the MAC address that both "Client A" and "Client B" gets from the ARP resolution of the "Server C" IP address. Right after the PING (on "Client A" and "Client B" versus "Server C"), runs (on both "Client A" and "Client B") an arp -an <ip.of.server.c>. You'll get something like:

verzulli@iMac-Chiara:~$ ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
[...]
verzulli@iMac-Chiara:~$ arp -an 192.168.2.1
? (192.168.2.1) associato a c0:c1:c0:e8:0f:12 [ether] su wlan0
verzulli@iMac-Chiara:~$

Here above you see that the MAC address of my "server" (192.168.2.1) is c0:c1:c0:e8:0f:12. In your case, ensure it's the same, for both "Client A" and "Client B". Again, please note that this is valid only if Client A and Client B are in the same ethernet segment of Server C.

If "Client A" and "Client B" are on different networks and/or "Server C" is far from them, then our only chance is to check what's coming to "Server C" when both "Client A" and "Client B" try to reach it. Unfortunately, here also we have a different approach depending on the relative location of the three hosts. Let's suppose the worst-case scenario: "Client A" and "Client B" connected to two different LANs (maybe two remote sites of a big-company) and "Server C" is connected to a third site (big-company headquarter). Both "Client A" and "Client B" are NATted, when reaching "Server C".

In such a case, we need to discover the "public" IP address assigned to "Client A" and "Client B" when reaching "Server C". There are plenty of ways to get this info. As a quick (...and very dirty) way to get result, you can launch:

verzulli@iMac-Chiara:~$ curl -s http://ipinfo.io | grep '"ip":'
  "ip": "2.239.77.181",

where you can see that my NAT-address (assigned by my provider to my host when leaving its network) is 2.239.77.181.

So, now, I can finally ask "Server C" to show me the traffic coming from my IP and.... just watch if something is really coming into.

On the server:

[root@srv-01 ~]# tcpdump -n -i eth0 host 2.239.77.181 and icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

it will.... start waiting, for incoming icmp (ping) packets coming from 2.239.77.181. As soon as I, from the client, will PING, such packets will be shown:

[root@srv-01 ~]# tcpdump -n -i eth0 host 2.239.77.181 and icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:28:21.031355 IP 2.239.77.181 > 78.47.127.152: ICMP echo request, id 60237, seq 1, length 64
16:28:21.031392 IP 78.47.127.152 > 2.239.77.181: ICMP echo reply, id 60237, seq 1, length 64

where you can see the PING (icmp echo request) coming from my client and, righafter, the reply from the server (icmp echo reply).

Should you prefer to check for every kind of traffic (and not only ICMP), you could try (on "Server C") with a:

tcpdump -n -i eth0 host 2.239.77.181

of, if you only want to check for HTTP traffic:

tcpdump -n -i eth0 host 2.239.77.181 and port 80

That's all.

Based on the above, you should be able to check if both "Client A" and "Client B" are reaching your "Server C" (and not two different web servers). Once got this info, get back here confirming this and... I could update this answer to step over.

Apache 2.4.7 mod_proxy_wstunnel tunneling too much (HTTP as well as WS)

anders' answer got me 95% of the way there.

The basic scenario:

We have a server on newapp.example.com
Port 8080 is running both HTTP and WebSockets
The URL that responds to WebSockets requests is /api/socket/
We're reverse-proxying this application as http://apps.example.com/newapp/

This is how to configure WebSockets and HTTP reverse-proxying for the above scenario in a <Location> block:

<Location /newapp/>
    ProxyPass http://newapp.example.com:8080/
    ProxyPassReverse /

    RewriteEngine on
    RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC]
    RewriteCond %{HTTP:CONNECTION} Upgrade$ [NC]
    RewriteRule /api/(.*) ws://newapp.example.com:8080/api/$1 [P]
</Location>

The final rewrite rule is crucial - without it, we'll pass the request /newapp/api/socket through to the WebSocket server - which it will reject.

The regex is parsing out everything after api - there might be a better way to capture that block, but this worked. We then have to remember to re-add /api/ to the final redirect URL.

Most importantly, HTTP requests continue to work after the WebSocket connection is established!

Best Answer

Related Solutions

Linux – Weird 302 response from apache server

Apache 2.4.7 mod_proxy_wstunnel tunneling too much (HTTP as well as WS)

Related Topic