alibabacloud-website-probe

Network Probe (Multi-Region Public Probing)

Multi-region availability probing over a single public probing backend (boce.aliyun.com). Run HTTP / DNS / Ping / MTR / traceroute tests from dozens of probe nodes spanning all major regions and the three nationwide carriers, typically returning within ~30-40 seconds. No account, no login, no cloud credentials of any kind.

Overview

Supported probe types: HTTP(S) web probing, DNS resolution checks, Ping, MTR, traceroute. All probes can optionally run from mobile 4G/5G perspective nodes (--mobile) instead of IDC backbone nodes.

Execution Principle

• Read-only: this skill only submits one-shot probes and reads results; it never modifies any configuration.
• Only the four scripts under scripts/ may be executed: boce_wrapper.py, boce_tool.py, analyze_boce_http.py, analyze_boce_dns.py. Ad-hoc probing of result JSON fields is forbidden: HTTP and DNS results are interpreted by the two analyze_boce_*.py scripts; Ping / MTR / traceroute results are interpreted from the per-node table that boce_wrapper.py prints itself.
• Results must be persisted to JSON on disk via the long-form --output flag (never the -o short form), then read through the reader above. Never rely on stdout alone.
• Probe only the target explicitly given by the user; never add, expand, or substitute probing targets.

Credentials

None required. This skill does not invoke any Alibaba Cloud OpenAPI. All probing goes through the public platform boce.aliyun.com, which is login-free: the scripts acquire an anonymous web session automatically. Do not ask the user for any account, AK/SK, STS token, or environment credential. See references/ram-policies.md.

Input Parameters

Collect from the user:

Probe type decision table:

Summary: the user only needs to provide the target; everything else can be inferred.

Probe Commands

All commands use relative paths from the skill directory.

HTTP wide-area probing

# HTTP wide-area probe (15 nodes, all three major carriers, ~30-40s)
python3 scripts/boce_wrapper.py http \
  --target "https:///" \
  --max-nodes 15 \
  --output /tmp/boce_http.json

# Analyze the results (dedicated script; ad-hoc field probing forbidden)
python3 scripts/analyze_boce_http.py /tmp/boce_http.json

Mobile perspective (add when the user mentions phone / 4G / 5G)

python3 scripts/boce_wrapper.py http \
  --target "https:///" \
  --max-nodes 10 --mobile \
  --output /tmp/boce_http_mobile.json

python3 scripts/analyze_boce_http.py /tmp/boce_http_mobile.json

DNS verification (add when dig results are in doubt)

python3 scripts/boce_wrapper.py dns \
  --target  \
  --output /tmp/boce_dns.json

# --expected: authoritative/expected A-record IPs, comma-separated
python3 scripts/analyze_boce_dns.py /tmp/boce_dns.json --expected 

Ping / MTR / traceroute

# Ping: per-node average / min / max RTT and packet-loss rate
python3 scripts/boce_wrapper.py ping --target  \
  --max-nodes 15 --output /tmp/boce_ping.json

# MTR: per-hop loss and latency along the path from each probe node
python3 scripts/boce_wrapper.py mtr --target  \
  --max-nodes 5 --output /tmp/boce_mtr.json

# traceroute: hop-by-hop RTT of the full path
python3 scripts/boce_wrapper.py traceroute --target  \
  --max-nodes 5 --output /tmp/boce_tr.json

These three types have no dedicated analyze script: the wrapper prints the per-node table (RTT / packet loss for Ping, per-hop TTL / loss / avg RTT for MTR and traceroute) after writing the JSON, and that printed table is the only permitted reading of the results. MTR and traceroute are slower per node, so keep --max-nodes small (~5) for them.

Probe Budget (mandatory defaults)

A single probe round takes ~15-40s and a full diagnosis should finish within about 10 minutes. Apply these budgets unless the user explicitly asks for wider coverage:

Never pad a diagnosis with "while at it" extra rounds to look thorough: more nodes cost wall-clock time without adding conclusion power beyond the regional/carrier split these defaults already provide.

Result Triage

Fallback

If the public probing platform is unavailable (session or API failure), degrade to local single-point verification with dig and curl:

dig +short  A
dig  @223.5.5.5 +short        # public resolver cross-check
curl -sSvo /dev/null -w '%{http_code} %{time_namelookup} %{time_connect} %{time_appconnect} %{time_starttransfer} %{time_total}\n' ""

MANDATORY FALLBACK DISCLAIMER (no exceptions). Whenever any local single-point verification (dig / curl) is used — whether as the primary evidence after a platform failure or as supplementary evidence after abnormal probing results — the final report MUST contain an explicit disclaimer using these exact phrases (keep them verbatim, answer in the user's language and provide the corresponding phrasing in it too):

Local dig/curl verification is single-vantage-point evidence and cannot prove or disprove regional differences.

Requirements:

• The disclaimer must appear in every deliverable that carries the conclusion: the final conversational reply itself AND any report file written to disk (e.g. outputs/*report*.md). Putting it only in the report file while the final reply states a bare conclusion is a violation (request_id=7607: the disclaimer existed in the report file but the final reply stated a global outage conclusion without it).
• Any conclusion drawn from local verification (including "globally unreachable") MUST carry this caveat in the same statement or an adjacent one; never state such a conclusion as a proven fact without it.
• This applies even when every probe failed: the correct structure is "probing platform returned no usable results + local single-vantage-point verification results + the disclaimer above" — never a bare global conclusion without the disclaimer.

Observability

• User-Agent template (mandatory): every request issued by the scripts carries a User-Agent built from the template AlibabaCloud-Agent-Skills/{SKILL_NAME}/{session-id}, where {SKILL_NAME} is this skill's frontmatter name — alibabacloud-website-probe — and {session-id} is the session identifier described below. Resolved example: AlibabaCloud-Agent-Skills/alibabacloud-website-probe/4eefc3a1be2102b3eb41463c84e98e9b.
• session-id rule: generated once per session, as a 32-char lowercase hex string, and kept consistent across CLI / SDK / Terraform and any other backend touched in that session. The value is cached for the whole run (get_run_session_id() in scripts/boce_tool.py) so that every request of one session reports the same id; it may be pinned externally via the SKILL_SESSION_ID environment variable, which is honoured only when it already is a valid 32-char lowercase hex string.
• This User-Agent is the only tracing marker this skill injects. The skill calls no Alibaba Cloud OpenAPI, so no STS assumption applies and the probing backend stays anonymous; the same UA template and session-id rule are still enforced on every outbound request.

Constraints

• Read-only: one-shot probes and result retrieval only.
• Strictly on-demand probing: probe only the target the user explicitly specified; never probe additional targets "while at it".
• No recreation on failure: if some nodes fail or time out, analyze the results already returned; do not resubmit new probe tasks unless the parameters were clearly wrong and the user agrees.
• Persist results: all probe results must be written to JSON via the long-form --output flag; HTTP and DNS analysis must go through analyze_boce_http.py / analyze_boce_dns.py, while Ping / MTR / traceroute are read from the wrapper's own printed table.
• Fallback disclaimer is mandatory: whenever local dig/curl single-point verification is used, the final report MUST state — using the exact wording from the Fallback section (and its faithful phrasing in the answer's language) — that it is single-vantage-point evidence and cannot prove or disprove regional differences; a global conclusion without this caveat is forbidden.
• --mobile pre-filters known-invalid city+carrier combinations (built-in blocklist embedded in scripts/boce_tool.py) to save ~15-20% runtime.

Deep Diagnosis Rules

When probes return errors or anomalies, the agent must load references/diagnostic-rules.md and follow its three-step flow. Vague conclusions such as "network error" or "operation timeout" are forbidden; every judgment must cite concrete result fields as evidence.

User Guidance

When the user asks exploratory questions ("what can this skill do?", "how do I use it?"), load references/user-guide.md and answer based on it. Do not copy user-guide.md content into SKILL.md.

Important Notes

• Probe runs take ~30-40s per round; follow the Probe Budget defaults so a full diagnosis finishes within ~10 minutes; two follow-up rounds take ~1-2 minutes total.
• Mobile probe nodes are scarce and the platform often returns only a fraction of submitted mobile nodes (e.g. 1-2 out of 10): treat partial mobile results as directional evidence, never wait for or resubmit to collect the full node list.
• The platform assigns no shareable web link to API-submitted probes; the taskId printed by the wrapper is for local traceability only.
• Overseas coverage is limited; prefer nationwide conclusions and state the coverage boundary when the user asks about overseas access.

Examples

Example 1: Regional HTTP fault isolation

User: "Users in some provinces say https://www.example.com returns 502, please check the scope."

python3 scripts/boce_wrapper.py http \
  --target "https://www.example.com" \
  --max-nodes 15 \
  --output /tmp/boce_http.json
python3 scripts/analyze_boce_http.py /tmp/boce_http.json

Reading: status-code distribution shows 200(12), 502(3) and the abnormal nodes share one province + one carrier → regional / carrier-scoped fault, not a global outage. Report the affected scope and the distinct targetIp of failing nodes as evidence.

Example 2: DNS hijacking verification

User: "www.example.com resolves to a strange IP for some users, the authoritative IP is 1.2.3.4."

python3 scripts/boce_wrapper.py dns \
  --target www.example.com \
  --output /tmp/boce_dns.json
python3 scripts/analyze_boce_dns.py /tmp/boce_dns.json --expected 1.2.3.4

Reading: the analyzer splits nodes into ok / polluted-overseas / polluted-invalid (0.0.0.0 or 127.x) / partial / empty and prints the carrier distribution of polluted nodes. Pollution concentrated on one carrier with errorCode=614 → carrier-side DNS hijacking / interception.