Budgeting China Access Checks: DNS Pollution and GFW Full Pricing Explained

A budget for checking domain access from mainland China needs more than a domain count. Check type, network coverage and frequency all affect planned usage. Checking 100 domains hourly creates 24 times the daily quantity of checking them once a day. Adding nodes to a GFW Full Domain Check changes the quantity again.

This guide uses public prices verified as of 11 October 2026. Its examples are arithmetic simulations, not customer billing records or measured detection runs. Prices can change; review current pricing and the actual estimate before use.

1. Choose the scope, then API or Console

Start with DNS Pollution Check when your question is whether a domain is reported as affected by DNS pollution. You do not select nodes for this method. Choose GFW Full Domain Check when you also need HTTP Host and TLS SNI observations and an overall assessment, using nodes relevant to your customers. GFW Full covers those three dimensions, not a full browser visit, a business transaction or all seven check methods.

Console suits platform-scheduled monitoring, history and alerts. API v2 suits batch checks with your own scheduling, result collection and storage. API and Console prices differ, but a unit-price comparison is not the whole decision: an API integration also needs request idempotency, scheduling and follow-up handling. See check methods and the GFW Full guide.

2. Billing units and current prices

DNS Pollution has no additional user-selected node multiplier. GFW Full uses its own combined-method price and the actual domain and node counts. Do not multiply that price by three because its results contain three dimensions. Separately requested methods use their own prices, not the combined-method rate.

Detection prices and account balances are in US dollars, not Chinese yuan or unspecified credits. Check each channel's current price; these figures are not a long-term quotation.

3. Calculate daily and monthly planned costs

Let D be domains, R be planned daily rounds, N be actual GFW nodes and P be the unit price for the chosen channel and method:

• DNS daily planned cost: D × R × P.
• GFW Full daily planned cost: D × N × R × P.
• A 30-day planned cost: daily planned cost × 30.

For continuous fixed-interval monitoring, daily rounds are 1440 divided by the interval in minutes. Consider two independent plans: 100 domains checked for DNS pollution every 60 minutes, and 20 domains checked with GFW Full on three actual nodes every 720 minutes. Assume 30 uninterrupted days, unchanged prices, all planned results accepted and no additional rechecks.

The columns are alternatives: all checks arranged through API versus all monitoring in Console, not a bill for using both channels. A domain included in both plans still receives two independent checks. Actual charges follow accepted results and the recorded price snapshots for those checks; pauses, errors, extra checks or configuration changes can change usage.

4. Budget with deliberate frequency and network coverage

Separate critical entry domains, important business domains and lower-frequency observation targets. If the 100-domain DNS plan instead runs every 120 minutes, it has 12 daily rounds: Console planned cost becomes $12.00 daily or $360.00 for 30 days. Keeping the GFW plan gives $13.20 daily or $396.00 for both. The reduction comes with less frequent observation, not identical coverage for free.

Choose GFW nodes around customer regions and carriers. A parent node code or "all" can expand into multiple currently available children. Three selected labels need not mean three actual nodes. Review planned_node_count in the API estimate and estimate again when the scope changes.

Deduplicate targets before submission, including case and internationalized-domain identity. Normalized duplicates can still become separate tasks. Overlap across batches, Console tasks or manual rechecks also belongs in the budget. Do not mistakenly merge distinct subdomains while cleaning the list.

5. Separate estimates, reservations and settlement

Send the final API parameters to /task/estimate before creation. Review unit_price, currency, planned_target_count, planned_node_count, planned_quantity, estimate_cost and available_balance. Estimation does not create a batch; creation does not mean completion. Estimate again after changing targets, nodes or method. Availability and prices can also change between estimation and creation.

API batch creation checks available funds, reserves pending costs and records the price at creation; Console uses the snapshot recorded for the corresponding monitoring round. Accepted valid results are charged using that snapshot, and unconsumed reservations are released. Balance, reserved funds and available balance are different values: an account balance is not necessarily entirely available for another task. Continuing Console monitoring also needs funds for subsequent rounds.

Under the published API v2 contract, timeouts, node errors and results rejected for insufficient balance are not charged. An abnormal target assessment, however, is not an invalid check. An accepted result reporting DNS pollution, HTTP Host reset or a TLS SNI anomaly can be billable; a normal verdict is not a payment condition. A legitimate HTTP response need not be 200 and does not prove the full website or transaction works. Nor does null alone determine billing. Read result semantics separately from the corresponding batch or monitoring round's billing records.

6. Use idempotent retries and query the original batch

Generate and persist one Idempotency-Key and the full request for each logical batch. If creation times out with uncertain acceptance, the same account, key and payload return the original batch without duplicate reservations or charges. A changed payload with that key returns 40901. Keys are retained with batch data for 24 hours; reuse after expiry becomes a new request, not permanent deduplication.

Once you have batch_id, query it rather than creating another batch to check progress. Repeated result reports, queries and pagination do not duplicate that check's charge. This is not a promise that all other services, new batches or rechecks are free. Preserve amount strings and use decimal types for accounting, not binary floating-point accumulation.

See the API documentation and DNS and GFW batch integration guide. Keep account keys out of articles, browser scripts and public logs.

7. Per-task and per-batch limits are not total allowances

Console currently accepts up to 200 domains per task. API v2 accepts 1–1000 targets per estimate or creation request. These are per-task and per-request boundaries, not a combined limit across all tasks or an included free allowance. Splitting an identical check plan into more tasks or batches does not reduce its billable quantity.

For larger lists, split targets and retain distinct idempotency keys and batch IDs for each logical batch. Budget across all targets, actual nodes and rounds. API v1 is synchronous and single-domain, not a batch request. Configure Console frequency from the current task editor; calculator examples do not add product capabilities.

8. A practical budget review checklist

1. Record each domain group's purpose and method, including intentional overlap between DNS and GFW plans.
2. Count unique targets, actual nodes, intervals and planned days. Budget extra rechecks separately.
3. Confirm USD prices on the pricing page; re-estimate final API parameters and review quantity and available balance. Keep headroom for subsequent monitoring rounds.
4. Save configurations, estimates, batch IDs and idempotency associations, but keep API credentials out of shared records. Preserve required API results and billing information before expiry.
5. Compare planned quantity, accepted results and actual cost for matching dates and methods. Investigate duplicates, expanded nodes, extra checks, pauses and rejected results before assuming a pricing problem.
6. Recalculate before changes and record when they take effect. Use Console for ongoing platform monitoring or the public API documentation for automation.

A useful budget explains both cost and coverage: which domains, which networks and how often. Define those choices and result storage first, then adjust usage deliberately.