Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- Check when the organization was created first. Creating a new token is not the same as creating a new organization.
- Check that credentials are passed consistently on the first request, pagination and retries.
- Use a read-only endpoint to compare the complete flow before and after the switch, checking the first response, redirects and business data.
Confirm the organization and applicable dates first
The October 2, 2026 announcement states that Zero Trust organizations created from October 5 onward must use strict authentication; existing organizations can toggle it.
Check the toggle state and record the environment and owner of the application and token.
Inventory the entire call chain, not just the first request
Authentication or authorization failures return 401/403 instead of a 302 redirect to a login page. Subsequent requests still need service-token headers.
List scheduled scripts, CI jobs, monitors and backend programs accessing the application, and identify a maintainer for each. For every caller, record its destination, credential-configuration location and the code that initiates the first request, pagination and retries. Record configuration names only, not credential values.
Follow the code from the task entry point to the actual HTTP request, marking configuration loading, request construction and response handling. Do not search only for a single variable name: wrapper libraries may read the same configuration in different functions. The inventory should identify the client used at every step.
Prepare policies and headers, then compare actual behavior
The standard two-header method uses CF-Access-Client-Id and CF-Access-Client-Secret for the Client ID and Client Secret respectively. Self-hosted Access applications can also configure single-header authentication; check those callers against their original configuration.
Ask the application owner to verify the actual requested path, corresponding policy and selected service token. Preserve existing required additional conditions; do not widen access as a substitute for investigation. Having token configuration does not mean the token is authorized for the target application.
Check where the client loads its configuration and whether the retrieved values match the intended settings. In particular, check whether pagination and retries use the same HTTP client. You can first use synthetic values to verify local request construction, checking that fields exist and their contents match. Do not send synthetic values to a real application or print real request headers.
Verify one complete flow in an isolated environment
Prepare an authorized test organization and application, with an administrator confirming the settings. Select a read endpoint with no write side effects and a clear expected response. Keep the caller and target unchanged, record results before switching, then compare results after switching in the test environment.
Cover at least the initial read and one subsequent read, checking status codes, redirects and whether the returned content is truly the expected data. Seeing a final 200 is insufficient: the HTTP library may already have followed a redirect. Recording the first response helps distinguish access-control results from business-endpoint results.
To cover failure branches, use test credentials prepared specifically in the isolated environment. Do not revoke production credentials to manufacture a fault. Confirm that the program stops or handles failure according to the established policy instead of retrying indefinitely. These are verification recommendations; this article has not performed account tests on the reader's behalf.
Schedule existing-organization switches; investigate one condition at a time
For existing organizations, open Zero Trust → Access controls → Access settings → Manage service tokens → Strict service token authentication, and confirm Enable.
After testing, have the owner coordinate checks for other callers in the same organization and schedule the switch. Save the original settings and verified client version. If any programs remain unverified, complete the inventory first; fixing only the immediate script could affect other services.
For 401/403, first determine whether the response came from access control or the business application, then compare the target path, selected credentials, transmitted fields and policy conditions. Compare the last successful configuration with the current failing one, condition by condition. The status code alone does not establish strict mode as the sole cause, nor show that all ordinary browser sign-ins are broken.
Use logs in the handoff; an empty result is not a conclusion
The service-token documentation states that expiry, deactivation, an incorrect Secret or missing application authorization for a recognized token are logged; malformed headers and unknown Client IDs are not. The separate logging documentation classifies service tokens as non-identity authentication, whose logs must be retrieved through the GraphQL Analytics API. The Cloudflare One dashboard does not provide those logs.
If the dashboard has no records, check the query method and time range before deciding whether to ask the logging maintainer for help. Do not conclude immediately that the request never reached Cloudflare, and do not relax policies merely to make a log appear.
Handoff material can include the time, target path, caller version, first response and conditions already checked. Remove credentials and sensitive business data from error bodies and screenshots first. Telling the next maintainer which evidence is still missing makes investigation easier than simply reporting that the token does not work.
Sources
Frequently Asked Questions
Is one successful request enough to switch?
You must also verify subsequent calls and other programs.
What should I provide when reporting to the maintainer?
Provide the time, target, caller version and comparisons already performed. Redact error details first and do not send raw credentials.