Tracing a click here page’s network requests
A page offering little more than a “Click here” link can still generate a substantial request chain. The visible destination may remain on the same domain, while the server response, redirect target and added query values tell a different story. Analysing that chain helps distinguish ordinary campaign attribution from an unnecessary download, opaque script load or off-site navigation.
Treat the investigation as reproducible observation rather than proof of intent. Record the starting URL, capture only traffic generated on a device you control, and note what was requested, by which page and when. It cannot, by itself, establish the owner’s motives, business model or the content of a destination the server chose not to return.
Set the scope before testing
Begin with an isolated browser profile and a written record of the starting address, date, time and device. Open the link once in a normal tab, then repeat it with the network log preserved. A screenshot before clicking establishes the visible content and prevents later assumptions. Keep query values in the record because they may connect one visit to an advertising campaign.
Only inspect traffic that you generate or have permission to capture. For an organisation, confirm that the test device, browser profile and any corporate proxy are approved for the investigation. In Australia, handling identifiers, device details or browsing histories can engage the Privacy Act 1988 and the Australian Privacy Principles, especially when the data is later stored or shared. The ACSC also publishes practical guidance on suspicious links and safe investigation.
Define what counts as third-party traffic. If the page contains outbound references, a link to a perennial planting guide may simply be a manually supplied destination, but its requests should be labelled as external rather than attributed to the original page. Record the initiating page, expected purpose and any cookies or scripts allowed to run before navigation.
Capture requests in the browser
Chrome and Edge provide a Network panel under developer tools; Firefox uses a similar panel. Enable Preserve log, clear existing entries, and record the click. The waterfall should reveal the HTML request, script activity, the response to the click and each subsequent navigation. Expand a request to compare its URL, method, status, initiator and headers. A JavaScript click handler may create traffic without a conventional 3xx response, making the Initiator column as important as the status.
Export a HAR file when finished, but review it first because saved captures can contain tokens, email addresses, advertising identifiers and cookie values. For a lightweight check outside the browser, curl -sS -D - -o /dev/null --max-redirs 10 'PASTE_THE_TEST_URL' displays redirect headers and limits the chain. Scripted requests do not always reproduce a browser’s GET, cookies or JavaScript, so use them as a comparison rather than a substitute for DevTools.
Run the same capture on home broadband and mobile data if that distinction matters. Australian users in Sydney, Melbourne, Brisbane and Adelaide often combine NBN-connected households with cellular connections, and the two paths can resolve the same hostname differently. A faster response on one path does not automatically mean a safer destination, but it is useful evidence when separating CDN delivery from a server-side delay.
Follow redirects and query strings
A server-side click usually produces a 301, 302, 303, 307 or 308 response with a Location header. Follow that header one hop at a time and note whether the hostname, scheme, path or port changes. A same-domain redirect can still add a parameter such as utm_source, gclid, fbclid, ref or a site-specific token. These names commonly support advertising attribution, yet their presence alone does not show that a tracking company received the visit.
Decode the query carefully and keep the raw and decoded forms. Look for nested url, redirect, continue or dest values, percent-encoded characters and repeated parameters. A chain that leaves the tested domain should be recorded separately from a same-domain path change. Also check whether the first response contains JavaScript that assembles the next URL, since source code and network headers may then tell different parts of the story.
Campaign links are familiar in the Australian retail market, where businesses in Sydney and Melbourne promote sales through email, social posts and SMS. A customer may arrive with a campaign identifier and then encounter a second redirect. Comparing the first request with one after removing non-essential parameters can show whether the parameter changes attribution, the destination or merely reporting. Repeat with a fresh profile because cookies can hide the difference.
Inspect scripts, cookies and timing
Read the response body as well as the headers. A minimal click-through page may return a short HTML document containing one anchor, while a script-heavy page may load analytics bundles, consent tools, advertising pixels or remote fonts. Click the Network panel’s Initiator and Dependency Tree entries to determine which script caused each request. Check Set-Cookie headers, but distinguish first-party analytics from embedded third-party trackers instead of treating every cookie as evidence of the same activity.
Suppose the log shows a script or redirect opening an online slots page. Classify that as cross-site navigation, then record its status, initiator and destination domain before deciding whether the request needs further investigation. Avoid loading an unfamiliar destination merely to satisfy curiosity; fetch only what is necessary and permitted, and avoid entering personal or payment information. A server response or redirect is sufficient to document the connection without interacting with the destination’s controls.
The timing waterfall separates DNS lookup, connection, TLS handshake, server wait and content download. Long gaps before the first byte point towards server or network delay, whereas a quick first byte followed by a slow transfer may indicate a large asset or throttled connection. Pay attention to repeated background requests that continue after the apparent destination has loaded. Those requests can update campaign metrics or open resources that are invisible on the original page.
Compare DNS and network paths
Wireshark or tcpdump can provide lower-level confirmation of DNS queries, IP connections and TLS handshakes when a browser capture needs corroboration. Apply narrow filters, capture only the test interface and avoid promiscuous collection on shared networks. Modern HTTPS protects the path and query string from passive observers, although destination hostnames may still be visible to the resolver or network operator unless encrypted DNS or other protections are in use.
If an observed target is a gambling terms page, identify it by the exact hostname rather than by a display name that could be copied or translated. Record the resolved IP address, response timing and whether it belongs to a CDN, cloud host or local endpoint. Then compare those values with a known Australian website, keeping in mind that services using an Australian domain such as .com.au can still use overseas infrastructure. Domain geography is a clue, not proof of the operator’s location.
Account for the route travelled by the test. NBN connections and mobile networks can reach different CDN edges, even within Australia. Some Canberra workplaces also route requests through a managed proxy. Record proxy and VPN settings; otherwise, an apparent IP change may be attributed incorrectly to the website.
Record evidence and communicate limits
Create an evidence log with one row per request. Useful fields include the local timestamp, request URL, method, status, redirect target, initiator, response type, destination IP, timing breakdown and relevant headers. Preserve a HAR, DNS record, screenshot and browser conditions, then hash any downloaded artefact that must be retained. Another analyst can then repeat the sequence and distinguish reproducible behaviour from a transient loading problem.
Write conclusions at the level supported by the evidence. For a page containing only a click link and a redirect with a tracking-style parameter, a defensible finding is that the navigation generated a same-domain request carrying campaign data. The capture may support a broader claim that external resources were loaded, but it does not establish the site’s purpose, services or subject matter. Avoid describing attribution as surveillance or deception unless additional evidence demonstrates that effect.
Redact personal information before sharing logs with a colleague, customer-support team, regulator or law-enforcement agency. Keep an untouched original where lawful, limit access to the evidence, and record any disclosure. If the page arrived through a suspicious message, report it through the relevant provider and use ACSC or Australian Signals Directorate resources for current advice. A carefully bounded report can say exactly which host received the request, which parameter changed and what the browser did next.