IP Diagnosis

Perform detailed network diagnosis on

macOS + Chrome

and output O&M reports with a fixed structure.

Applicable Scenarios

Use this skill when users request the following tasks:

Check current public network
```
IPv4
```
/
```
IPv6
```
Determine if there is region split between
```
IPv4/IPv6
```
Check if VPN/proxy only takes over part of the traffic
Check if the browser side exposes extra addresses
Compare command line egress results with results seen on browser pages
Output a detailed reviewable network diagnosis report

This skill runs on the current machine by default, no confirmation prompt will be sent before execution.

Implementation Principles

Install missing dependencies first before diagnosis
Check local network stack first, then external egress, then browser cross-validation
Cross-validate with at least two external sources, do not rely on a single site
Clearly distinguish in the report:
- Verified facts
- Judgments
- Suggestions
Public IP seen in
```
Server Response
```
does not equal browser leak by itself
Only when extra private network or abnormal public network addresses are exposed via
```
WebRTC
```
, it is judged as browser-side leakage risk

0. Dependency Check and Installation

Check first:

bash

command -v curl
command -v dig
command -v jq
command -v python3
command -v npm
command -v playwright-cli
command -v brew
open -Ra "Google Chrome"

Default dependencies:

```
curl
```
```
dig
```
```
jq
```
```
python3
```
```
npm
```
```
playwright-cli
```
```
Google Chrome
```

Installation rules:

If
```
playwright-cli
```
is missing,
```
npm
```
does not exist and
```
brew
```
is available:
bash
```
brew install node
```

playwright-cli

is missing:

bash

npm install -g playwright-cli

Verify immediately after installation:
bash
```
playwright-cli open --help
```
If
```
Google Chrome
```
does not exist, clearly state the blocking item and stop; do not automatically downgrade to other browsers
If
```
playwright-cli
```
can run but the chrome browser channel cannot be opened, try:
bash
```
playwright-cli install-browser --browser chrome
```
If
```
jq
```
is missing and
```
brew
```
is available:
bash
```
brew install jq
```
If
```
python3
```
is missing and
```
brew
```
is available:
bash
```
brew install python
```

If key dependencies cannot be installed, clearly state the blocking item in the report and stop, do not forge conclusions.

1. Local Network Stack Check

Execute in order:

bash

route -n get default
route -n get default | awk '/interface:/{print $2}'
networksetup -listallhardwareports
netstat -rn -f inet6 | sed -n '1,80p'
scutil --dns
ifconfig | grep -E -A3 '^(en0|en1|utun[0-9]+):'

Then:

Extract the current default interface from
```
route -n get default
```
first, e.g.
```
en0
```
Map the interface to the corresponding network service name with
```
networksetup -listallhardwareports
```
Only execute after mapping to a clear service name:

bash

networksetup -getinfo "<actual service name>"

If mapping fails, write
```
networksetup service unresolved
```
in the report, do not hardcode it as
```
Wi-Fi
```

Objectives:

Check the direction of the default route
Check if the
```
IPv6
```
default route goes through
```
utun
```
Check if there is an active
```
utun
```
Check if the local interface has native
```
IPv6
```
Check if DNS is a tunnel private resolver or local direct resolver

2. Local Command Confirmation of Public Egress

Execute at least:

bash

curl --connect-timeout 8 --max-time 15 -4sS https://api.ipify.org
curl --connect-timeout 8 --max-time 15 -6sS https://api64.ipify.org
curl --connect-timeout 8 --max-time 15 -4sS https://ipinfo.io/json
curl --connect-timeout 8 --max-time 15 -6sS https://ipinfo.io/json
curl --connect-timeout 8 --max-time 15 -4sS https://ifconfig.co/json
curl --connect-timeout 8 --max-time 15 -6sS https://ifconfig.co/json
curl --connect-timeout 8 --max-time 15 -4sS https://api.ip.sb/geoip
curl --connect-timeout 8 --max-time 15 -6sS https://api.ip.sb/geoip
dig +short txt ch whoami.cloudflare @1.1.1.1

Requirements:

Confirm
```
IPv4
```
and
```
IPv6
```
separately
Try to get for both:
- IP
- Country/Region
- ASN
- Organization
If
```
-6
```
query fails, do not immediately judge "no IPv6"
If the result is
```
::ffff:x.x.x.x
```
and other
```
IPv4-mapped IPv6
```
addresses, do not treat it as an independent public
```
IPv6
```

3. Chrome Browser Cross-Validation

Must use:

webbrowsertools IP Address

Recommended execution order:

bash

playwright-cli open --browser=chrome https://webbrowsertools.com/ip-address/
playwright-cli eval "document.title"
playwright-cli eval "document.body.innerText"
playwright-cli snapshot

If needed, you can read additionally:

bash

playwright-cli console
playwright-cli network

If any of the following occurs:

Page title or body contains
```
请稍候
```
Page title or body contains
```
Just a moment
```
Page title or body contains
```
Verify you are human
```
The page content is obviously a
```
Cloudflare
```
challenge page
```
playwright-cli network
```
or console shows main page request returns
```
403
```
Key groups such as
```
IP Addresses
```
,
```
From Server Response
```
,
```
Via WebRTC
```
are missing on the page

Perform a limited retry:

bash

playwright-cli close
playwright-cli open --browser=chrome --headed --persistent https://webbrowsertools.com/ip-address/
playwright-cli eval "document.title"
playwright-cli eval "document.body.innerText"
playwright-cli snapshot

If it is still a challenge page, 403, or missing key groups after retry:

Do not fail the entire diagnosis
Write the browser cross-validation status as
```
blocked by challenge / partial / unavailable
```
in the report
Clearly record the title, error, 403 or challenge page prompt seen
Continue to complete the report for the local network stack and external egress parts
Mark
```
webbrowsertools
```
as "browser-side verification blocked, manual review required"

Record these dynamic result groups in as much detail as possible in the report:

```
IP Addresses
```
```
From Server Response
```
```
Remote Data
```
```
Remote IP Services
```
```
Via WebRTC
```

If specific lines are visible on the page, list them item by item as much as possible, do not make simple summaries.

Key fields usually include:

```
HTTP_CLIENT_IP
```
```
HTTP_CONNECTING_IP
```
```
HTTP_COUNTRY_CODE
```
```
HTTP_X_FORWARDED
```
```
HTTP_X_CLUSTER_CLIENT_IP
```
```
HTTP_FORWARDED_FOR
```
```
HTTP_FORWARDED
```
```
ipapi.co
```
```
hostip.info
```
```
ipify.org [IPv4]
```
```
ipify.org [IPv6]
```
```
ipecho.net
```
Various
```
STUN/WebRTC
```
lines

4. Report Output Format

Must output according to the following structure.

Conclusion

Network status:

Normal / Risk pending confirmation / Obviously abnormal

One-sentence summary of the most critical problem

Conclusion judgment requirements:

If the active network service clearly shows
```
IPv6 Off
```
, and:
- Command line egress is consistent with browser side
- No extra addresses via
```
WebRTC
```
- No evidence of independent public
```
IPv6
```
  Write
```
Normal (IPv6 is turned off)
```
  by default
In the above scenario, do not write
```
Risk pending confirmation
```
just because
```
IPv6
```
is not confirmed
Only upgrade to
```
Risk pending confirmation
```
when there is actual inconsistency, abnormal exposure, challenge page blocking key verification, or
```
IPv6
```
is still active but status is unclear

Evidence

Local Check

```
IPv4
```
:
```
<ip or unconfirmed>
```
```
IPv6
```
:
```
<ip or unconfirmed>
```
```
DNS
```
:
```
<resolver summary>
```
```
Default route
```
:
```
<gateway / interface>
```

utun

<exists / does not exist + brief description>

Local interface
```
IPv6
```
:
```
<summary>
```

External Egress

```
IPv4
```
- IP
- Country/Region
- ASN
- Organization
- Source 1
- Source 2
```
IPv6
```
- IP
- Country/Region
- ASN
- Organization
- Source 1
- Source 2

If a source fails, clearly write:

```
Failed to fetch
```
```
timeout
```
```
blocked
```
```
No evidence of independent public IPv6
```
```
To be verified
```

If the active network service clearly shows

IPv6 Off

, and the local interface has no global

IPv6

IPv6

evidence is preferentially written as

No evidence of independent public IPv6 (IPv6 is turned off)

Do not preferentially write
```
To be verified
```

The

IPv6 is turned off

here is subject to the

IPv6: Off

returned by

networksetup -getinfo "<actual service name>"

Browser Cross-Validation

Page: webbrowsertools IP Address

Browser cross-validation status:

success / partial / blocked by challenge / unavailable

```
IP Addresses
```
All items of
```
From Server Response
```
All items of
```
Remote Data
```
All items of
```
Remote IP Services
```
All items of
```
Via WebRTC
```

Judgment

Must explicitly answer:

Is there
```
IPv4/IPv6
```
region split:
```
Yes / No / To be verified
```
Is the command line egress consistent with the browser side:
```
Yes / No / Partially consistent
```
Is there browser-side
```
WebRTC
```
leak:
```
Yes / No / To be verified
```
Is the public address seen in
```
Server Response
```
just a normal phenomenon of direct connection to the website:
```
Yes / No
```
Is the existence of independent public
```
IPv6
```
confirmed:
```
Yes / No / To be verified
```
Is browser cross-validation blocked by challenge page or 403:
```
Yes / No
```

Solution

Each suggestion should include:

Applicable conditions
Action
Why it works

Suggestions are sorted in descending order of priority.

If the country/region of

IPv4

and

IPv6

are inconsistent, you must give the specific method to turn off

IPv6

macOS

bash

networksetup -listallnetworkservices
networksetup -setv6off "Wi-Fi"

If recovery is needed, supplement:

bash

networksetup -setv6automatic "Wi-Fi"

And clearly prompt the user: if the currently used network service is not

Wi-Fi

, first find the correct service name from the output of

networksetup -listallnetworkservices

before execution.

If it is observed that

Via WebRTC

exposes extra private network or abnormal public network addresses, you can use Chrome extension as one of the browser-side mitigation options:

WebRTC Protect - Protect IP Leak

Description points:

This extension reduces private and public network address exposure by adjusting the browser's
```
WebRTC
```
routing and privacy settings
It may affect audio/video or real-time communication sites that rely on
```
WebRTC
```
Only applicable to
```
WebRTC
```
exposure problems, does not solve the
```
Server Response
```
seen by the website through normal direct connection requests

If it is observed that the

AS Name

ASN

displayed by some sites is inconsistent with the attribution of the current

HTTP

egress

IP

, add a low-priority suggestion:

Applicable conditions:
```
HTTP
```
egress
```
IP
```
is consistent with most external sources, but the
```
DNS ASN
```
/
```
AS Name
```
displayed by a site points to another organization or operator
Action: Clearly tell the user that this is usually the attribution of the
```
DNS
```
resolver, not an extra public
```
IP
```
leak; the user decides whether to continue processing on their own
Why it works: Some sites detect both
```
HTTP
```
egress and
```
DNS
```
resolver at the same time, the
```
AS Name
```
on the page may reflect the
```
ASN
```
of the recursive resolver, not the
```
ASN
```
of the current web page connection egress

If the user decides to continue processing this problem, only use the following actions as options, do not recommend them as mandatory fixes by default:

Manually modify
```
macOS
```
system
```
DNS
```
Switch to accessible
```
DoH
```
in the proxy/VPN client
Switch to a client or mode that can stably take over system
```
DNS
```

And clearly explain:

Separate
```
DNS ASN
```
exposure is usually not treated as high risk
Whether to process depends on the user's tolerance for operator exposure, resolution link consistency and maintenance cost

Review Links

Include at least:

webbrowsertools IP Address
Links or domain names of external query sources used this time

If the specific public IP has been confirmed, it is recommended to additionally provide review links that directly include the IP:

```
https://ping0.cc/ip/<detected-ip>
```
```
https://iplark.com/<detected-ip>
```
```
https://ipinfo.io/<detected-ip>
```

The

<detected-ip>

here should be replaced with the actual

IPv4

IPv6

confirmed in the report, do not hardcode it as a historical example value.

When

WebRTC

exposure is part of the problem, provide together:

WebRTC Protect - Protect IP Leak

5. Interpretation Rules

Public IP seen in
```
From Server Response
```
:
- This is naturally visible for direct website connection, do not automatically judge it as browser leak
Only when extra private network or abnormal public network addresses are exposed via
```
WebRTC
```
:
- Judge it as browser-side leakage risk
Different country/region for
```
IPv4
```
and
```
IPv6
```
:
- Judge as region split risk
- The solution preferentially includes the specific command to turn off
```
IPv6
```
  on
```
macOS
```
```
IPv6
```
query fails, but local interface and routing table still show
```
IPv6
```
:
- Write
```
IPv6 status to be verified
```
If the active network service clearly shows
```
IPv6 Off
```
, the local interface has no global
```
IPv6
```
, and external sources have no evidence of independent public
```
IPv6
```
:
- Write
```
No
```
  for
```
Is the existence of independent public IPv6 confirmed
```
- Write
```
No (IPv6 is turned off)
```
  for
```
Is there IPv4/IPv6 region split
```
- Do not upgrade the conclusion to
```
Risk pending confirmation
```
  by default for this reason
- ```
fe80::
```
  on
```
utun
```
  , link-local
```
IPv6
```
  addresses, or residual
```
inet6
```
  routes cannot overturn this conclusion alone
Conflicts in ASN/organization/region among multiple sources:
- Clearly write
```
Sources are inconsistent, review required
```
If the
```
AS Name
```
/
```
ASN
```
displayed by the site conflicts with the attribution of the
```
HTTP
```
egress
```
IP
```
, but the
```
HTTP
```
egress
```
IP
```
itself is consistent on most sources:
- First judge whether the site also detects the
```
DNS
```
  resolver
- Preferentially write
```
DNS ASN is inconsistent with HTTP egress ASN
```
- Do not directly write
```
Hidden real IP found
```
  or
```
Extra public IP leak occurred
```
- Treat as low-risk information exposure by default, and leave it to the user to decide whether to continue convergence
No evidence of independent public
```
IPv6
```
:
- Can only write
```
Independent public IPv6 not confirmed
```
- Do not write
```
IPv6 is normal
```

6. Recommended External Sources

Prioritize these sources for cross-validation:

Among them,

webbrowsertools

is only used as a browser cross-validation page, not as the only source of truth.

7. Prohibited Items

Do not quote only one IP query site
Do not only check
```
IPv4
```
Do not skip browser cross-validation
Do not directly write
```
Server Response
```
as browser leak
Do not treat the failure of a single external site as the final conclusion
Do not make hasty conclusions before confirming the
```
IPv6
```
status

ip-diagnosis

NPX Install

Tags

SKILL.md Content (Chinese)

IP Diagnosis

Applicable Scenarios

Implementation Principles

0. Dependency Check and Installation

1. Local Network Stack Check

2. Local Command Confirmation of Public Egress

3. Chrome Browser Cross-Validation

4. Report Output Format

Conclusion

Evidence

Local Check

External Egress

Browser Cross-Validation

Judgment

Solution

Review Links

5. Interpretation Rules

6. Recommended External Sources

7. Prohibited Items