OSS Transfer Acceleration Diagnosis

Diagnose Alibaba Cloud OSS transfer acceleration problems: "I enabled transfer acceleration but downloads from overseas are still slow", "is oss-accelerate.aliyuncs.com the right endpoint for my cross-border access", "what is the difference between the OSS accelerator and transfer acceleration", "why am I billed for transfer acceleration traffic".

Core approach: verify the caller identity, fetch the bucket metadata with the read-only GetBucketInfo control-plane query, read the bucket's transfer-acceleration status with the read-only GetBucketTransferAcceleration query (measured on oss2 2.19.1: OSS answers 404 NoSuchTransferAccelerationConfiguration when the feature was never enabled - that 404 is the "feature disabled" finding, not an error), then run a pure-function decision tree: feature enabled + client still on a plain endpoint -> acceleration not taking effect (endpoint never replaced); accelerate domain in use while the feature is disabled -> requests will fail until the user enables the feature; selection questions are answered by a fixed product matrix (Data Accelerator = same-region hot-data caching; Transfer Acceleration = cross-border/cross-region link optimization); fee questions are answered with the official billing semantics. Conclude with evidence-based findings only; this skill never enables, disables, or changes anything.

Absolute Rules

1. ABSOLUTE PROHIBITION (read-only enforcement): Under NO circumstances may you generate, write, or execute any command/script calling a mutating OSS API - e.g. the transfer-acceleration switch (oss2 put_bucket_transfer_acceleration / the console Enable action), any ACL/policy/lifecycle/CNAME change, or any object/bucket mutation. Enabling transfer acceleration is described as manual guidance in words only and is executed by the user in the OSS console. If the user asks to enable/disable the feature, only output the guidance and declare this skill is read-only.
2. MANDATORY entry-point enforcement: All OSS diagnostics MUST be performed by running the scripts under scripts/ (oss_transfer_acceleration_diagnosis.py as the entry, sts_token.py for identity). The Agent is forbidden from assembling its own ossutil / SDK / curl commands against the 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. The scripts already resolve the default credential chain for you - ALIBABA_CLOUD_ACCESS_KEY_ID / ALIBABA_CLOUD_ACCESS_KEY_SECRET / ALIBABA_CLOUD_SECURITY_TOKEN environment variables first, then the current aliyun CLI profile (~/.aliyun/config.json) - entirely in memory. Therefore parsing, cat-ing, or exporting values from that config file is forbidden too: if a query degrades with NoCredentials, record the degradation and continue the report; never "bridge" credentials yourself. Never accept AK/SK from the user or from another script.
4. NO FABRICATION: Every conclusion must be grounded in data actually returned by GetBucketInfo / GetBucketTransferAcceleration / ListBuckets / GetCallerIdentity. If a query fails or returns empty, record it and state the limitation - never invent the enablement status, and never fabricate method names or APIs. If the transfer-acceleration status cannot be queried at all (permission gap / interface unavailable), degrade to the user-provided evidence form: ask for a console screenshot or a plain-language status description of the bucket's Transfer Acceleration page, run the knowledge-based judgment on that evidence, and declare the evidence source explicitly.
5. EXECUTION RULE FOR ERRORS: On any API error, log [WARN] <category>: <message> to stderr, continue with the remaining steps (including the ListBuckets fallback and the real-region retry), and still produce the final report with STATUS: DEGRADED and a NEXT_ACTION line - never silently skip or abort without a report.
6. SCOPE BOUNDARY: This skill only answers transfer-acceleration adoption ("not taking effect") detection, Data-Accelerator-vs-Transfer-Acceleration selection, cross-border slowness attribution, and fee-semantics explanation. It does NOT handle bill line-item attribution (defer to the billing skill), plain internal/public endpoint and region choice (defer to the endpoint skill), multipart fragment issues (defer to the multipart-upload diagnosis skill), or presigned URL errors (defer to the presigned-url-v4 diagnosis skill).

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.