SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsip-diagnosis

ip-diagnosis

General & other

View repository

Updated 10-15 17:24

About this skill

IP Diagnosis

On macOS + Chrome perform detailed network diagnostics and output an operations report with a fixed structure.

Use cases

Use this skill when the user requests the following tasks:

  • Check the current public IPv4 / IPv6
  • Determine whether IPv4/IPv6 has region splitting
  • Check whether VPN / proxy only takes over part of the traffic
  • Check whether the browser side exposes additional addresses
  • Compare the command-line egress with the results seen on the browser page
  • Output a reviewable detailed network diagnostic report

This skill targets the current machine by default and does not ask whether to continue.

Execution principles

  1. Install dependencies first, then perform diagnostics
  2. Local network stack first, then external egress, then browser cross-validation
  3. Cross-validate with at least two types of external sources, do not rely on a single site
  4. In the report, clearly distinguish:
    • Proven facts
    • Judgment
    • Recommendations
  5. Server Response Seeing the public IP does not itself equal browser leakage
  6. Only when Via WebRTC exposes additional private network or abnormal public addresses should browser-side leakage risk be determined

0. Dependency check and installation

Check first:

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 but npm does not exist, and brew is available: 
    brew install node
  • If playwright-cli is missing: 
    npm install -g playwright-cli
  • Verify immediately after installation: 
    playwright-cli open --help
  • If Google Chrome does not exist, explicitly write out the blocker and stop; do not automatically fall back to another browser
  • If playwright-cli can run, but the chrome browser channel cannot be opened, then try: 
    playwright-cli install-browser --browser chrome
  • If jq is missing and brew is available: 
    brew install jq
  • If python3 is missing and brew is available: 
    brew install python

If key dependencies cannot be installed, explicitly write out the blocker in the report and stop; do not fabricate conclusions.

1. Local network stack check

Execute in order:

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:

  • First extract the current default interface from route -n get default , for example en0
  • Then use networksetup -listallhardwareports to map the interface to the corresponding network service name
  • Only after mapping to an explicit service name, execute:
networksetup -getinfo "<实际服务名>"
  • If it cannot be mapped, write in the report networksetup service unresolved, do not hard-code it as Wi-Fi

Goal:

  • See where the default route goes
  • See whether the IPv6 default route goes via utun
  • See whether there is an active utun
  • See whether the local interface has native IPv6
  • See whether DNS looks like a tunnel private network resolver or a local directly connected resolver

2. Confirm the public egress with local commands

At least execute:

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
  • Try to obtain for both:
    • IP
    • Country / region
    • ASN
    • Organization
  • If -6 the query fails, do not immediately conclude "no IPv6"
  • If the result is ::ffff:x.x.x.x of this kind IPv4-mapped IPv6, do not treat it as an independent public IPv6

3. Chrome browser cross-validation

Must use:

Recommended order:

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 may also read:

playwright-cli console
playwright-cli network

If any of the following occurs:

  • The page title or body contains 请稍候
  • The page title or body contains Just a moment
  • The page title or body contains Verify you are human
  • The page content is clearly a Cloudflare challenge page
  • playwright-cli network or the console shows the main page request 403
  • Cannot see in the page IP Addresses、From Server Response、Via WebRTC these key groups

then perform one limited retry:

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 after the retry it is still a challenge page, 403, or key groups are missing:

  • Do not let the entire diagnosis fail
  • In the report, write the browser cross-validation status as blocked by challenge / partial / unavailable
  • Clearly record the title, error, 403, or challenge page prompt that was seen
  • Continue to complete the report on the local network stack and external egress parts
  • Mark webbrowsertools as "browser-side validation blocked, manual review required"

In the report, record these dynamic result groups in as much detail as possible:

  • 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 simply summarize.

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:正常 / 有保留风险 / 明显异常
  • Summarize the most critical issue in one sentence

Conclusion determination requirements:

  • If active network services clearly show IPv6 Off, and:
    • The command-line egress matches the browser side
    • No Via WebRTC extra address
    • No evidence indicates the existence of an independent public IPv6 then by default write it as 正常（IPv6 已关闭）
  • is not confirmed IPv6 merely because 有保留风险
  • Only when there is an actual inconsistency, abnormal exposure, a challenge page blocking key validation, or IPv6 is still active but its status is unclear, escalate to 有保留风险

Evidence

Local check

  • IPv4：<ip 或 未确认>
  • IPv6：<ip 或 未确认>
  • DNS：<解析器摘要>
  • Default route：<网关 / 接口>
  • utun：<存在 / 不存在 + 简述>
  • Local interface IPv6：<摘要>

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, explicitly write:

  • Failed to fetch
  • timeout
  • blocked
  • 无独立公网 IPv6 证据
  • 待核实

If active network services clearly show IPv6 Off, and the local interface has no global IPv6：

  • IPv6 evidence should preferably be written as 无独立公网 IPv6 证据（IPv6 已关闭）
  • Do not preferably write it as 待核实
  • Here IPv6 已关闭 is based on the networksetup -getinfo "<实际服务名>" returned by IPv6: Off as authoritative

Browser cross-validation

  • Page: webbrowsertools IP Address
  • Browser cross-validation status:success / partial / blocked by challenge / unavailable
  • IP Addresses
  • From Server Response each item
  • Remote Data each item
  • Remote IP Services each item
  • Via WebRTC each item

Judgment

Must explicitly answer:

  • Whether there is IPv4/IPv6 regional split:是 / 否 / 待核实
  • Is the command-line exit consistent with the browser side:是 / 否 / 部分一致
  • Whether there is a browser-side WebRTC leak:是 / 否 / 待核实
  • Server Response Whether the public address seen in is merely the normal phenomenon of a direct website connection:是 / 否
  • Whether an independent public IPv6：是 / 否 / 待核实
  • Whether browser cross-verification is blocked by a challenge page or 403:是 / 否

Solution

Each recommendation must state:

  • Applicable conditions
  • Action
  • Why it is effective

Recommendations are ordered from highest to lowest priority.

If it is observed that IPv4 and IPv6 countries/regions are inconsistent, the specific way to macOS disable IPv6 must be given:

networksetup -listallnetworkservices
networksetup -setv6off "Wi-Fi"

If restoration is needed, add:

networksetup -setv6automatic "Wi-Fi"

and clearly remind the user: if the network service currently in use is not Wi-Fi, first find the correct service name from the networksetup -listallnetworkservices output before executing.

If it is observed that Via WebRTC exposes additional private-network or abnormal public addresses, the Chrome extension can be listed as one of the browser-side mitigation options:

Key points to explain:

  • This extension reduces private-network and public-address exposure by adjusting the browser's WebRTC routing and privacy settings
  • It may affect audio/video or real-time communication sites that depend on WebRTC audio/video or real-time communication sites
  • It only applies to WebRTC exposure issues, and does not solve the Server Response

seen by websites through normal direct requests AS Name / ASN If it is observed that the HTTP displayed by some sites is inconsistent with the attribution of the current IP exit

  • , add a low-priority recommendation:HTTP Applicable conditions: IP exit DNS ASN / AS Name is consistent with most external sources, but the
  • shown by a certain site points to another organization or carrier DNS Action: clearly tell the user that this is usually IP resolver attribution, not an additional public
  • leak; the user decides whether to continue handling it HTTP Why it is effective: some sites detect both the DNS exit and the AS Name resolver, and the ASNon the page may reflect the recursive resolver's ASN

, rather than the

  • of the current web page connection exit macOS If the user decides to continue handling this issue, treat only the following actions as optional, and do not recommend them by default as must-fix: DNS
  • Manually modify the DoH
  • system DNS In the proxy / VPN client, switch to a reachable

Switch to a client or mode that can stably take over the system

  • and clearly state: DNS ASN exposure alone is usually not treated as high risk
  • Whether to handle it depends on the user's tolerance for carrier exposure, resolver path consistency, and maintenance cost

Recheck links

Include at least:

If a specific public IP has already been confirmed, it is recommended to additionally provide a recheck link that directly includes that IP:

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

Here, the <detected-ip> should be replaced with the actual IPv4 or IPv6confirmed in the report; do not hardcode it to historical example values.

When WebRTC exposure is part of the problem, also provide:

5. Interpretation rules

  • From Server Response see public IP:
    • This is naturally visible to the directly connected website and is not automatically judged as a browser leak
  • Only Via WebRTC exposes additional private network or abnormal public network addresses:
    • only then is it judged as a browser-side leak risk
  • IPv4 and IPv6 country/region differs:
    • judge as region split risk
    • The solution should preferentially include macOS the specific command to disable IPv6 specific command for
  • IPv6 query failed, but the local interface and routing table still show IPv6：
    • write as IPv6 状态待核实
  • If the active network service clearly shows IPv6 Off, and the local interface has no global IPv6, and external sources also have no independent public IPv6 evidence:
    • 是否确认存在独立公网 IPv6 write 否
    • 是否存在 IPv4/IPv6 地区分裂 write 否（IPv6 已关闭）
    • By default, the conclusion should not be escalated because of this to 有保留风险
    • utun on fe80::, link-local IPv6 address, or residual inet6 route; this alone cannot overturn this conclusion
  • Multiple sources conflict on ASN / organization / region:
    • clearly write 来源不一致，需复查
  • If the site displays AS Name / ASN and HTTP egress IP attribution conflict, but HTTP egress IP itself is consistent across most sources:
    • first determine whether the site also detects DNS resolver
    • prefer to write as DNS ASN 与 HTTP 出口 ASN 不一致
    • do not directly write as 发现隐藏真实 IP or 发生额外公网 IP 泄露
    • By default, treat it as low-risk information exposure and leave it to the user to decide whether to continue converging
  • No independent public IPv6 evidence:
    • can only write 未确认独立公网 IPv6
    • do not write as IPv6 正常

6. Recommended external sources

Prefer these sources for cross-verification:

Among them, webbrowsertools is only used as a browser cross-verification page, not as the sole source of truth.

7. Prohibitions

  • Do not cite only one IP lookup site
  • Do not look only at IPv4
  • Do not skip browser cross-verification
  • Do not write Server Response directly as a browser leak
  • Do not treat the failure of a single external site as the final conclusion
  • Do not hastily draw a conclusion before confirming IPv6 status