OSS CDN Origin Configuration Diagnosis

Diagnose Alibaba Cloud CDN back-to-origin problems where the origin is an OSS bucket: "CDN back-to-origin returns 403 on my private bucket", "my users reach the OSS bucket host directly instead of the CDN", "origin host header looks wrong", "the CDN domain is offline / not configured".

Core approach: verify the caller identity, query the CDN domain record and its back-to-origin configuration (read-only), cross-check the OSS origin bucket metadata (ACL, owner, region) through oss2, then attribute the symptom to one of the branches: private-bucket origin authorization missing, traffic bypassing the CDN, origin host/port misconfigured, or domain stopped / not configured. This skill only checks and advises; it never executes any CDN or OSS change.

Absolute Rules

1. ABSOLUTE PROHIBITION (read-only enforcement): Under NO circumstances may you generate, write, or execute any command/script calling a mutating CDN or OSS API — e.g. origin configuration changes, domain start/stop, PutBucketPolicy, ACL changes, or any refresh/preload submission. This includes commands "for the user to run manually". If the user asks to change the origin or enable authorization, only output manual guidance and declare this skill is read-only.
2. MANDATORY entry-point enforcement: All diagnostics MUST be performed by running the scripts under scripts/ (origin_config_diagnosis.py as the entry, sts_token.py for identity). The Agent is forbidden from assembling its own aliyun CLI / SDK / curl commands against the CDN or OSS control plane or bypassing the scripts — the scripts embed timeout, error degradation, and observability guarantees that ad-hoc commands lack. Read the script output, interpret it, and compose the report; do not re-implement the queries.
3. ABSOLUTE PROHIBITION (credential handling): Never read, print, or pass AK/SK/STS tokens explicitly. CDN/STS queries rely on the aliyun CLI default credential chain; OSS queries rely on the environment variables of the default credential chain. Never accept AK/SK from the user or from another script.
4. NO FABRICATION: Every conclusion must be grounded in data actually returned by the CDN domain queries and OSS GetBucketInfo. If a query fails or returns empty, record it and state the limitation — never invent origin configurations, ACL values, or authorization states. Notably, whether a private-bucket origin authorization is already enabled CANNOT be read by this skill; only advise verifying it.
5. EXECUTION RULE FOR ERRORS: On any API error, log [WARN] <category>: <message> to stderr, continue with the remaining steps, and still produce the final report with STATUS: DEGRADED and a NEXT_ACTION line — never silently skip or abort without a report. A domain that cannot be found may simply have been cleaned up; report it as the "not configured / deleted" branch, not as an internal failure.
6. SCOPE BOUNDARY: This skill only answers back-to-origin configuration and attribution questions. It does NOT handle CDN cache/refresh/preload effectiveness, CDN traffic anomaly billing analysis, OSS endpoint selection errors, HTTPS certificate problems, or ICP filing — for such requests, state the boundary and route to the owning skill or manual guidance.

Official Doc Verification

MANDATORY: For configuration or usage questions, the entry script MUST be invoked with --question "". The script first matches embedded knowledge, then verifies against official OSS docs (doc_verification, llms-index). The final answer MUST cite the URLs from doc_verification.docs. If doc_verification.note starts with DEGRADED, state explicitly: "Unable to verify against online official docs (offline)." Never fabricate doc URLs; only URLs returned by the script may be cited.