Tencent Cloud Business Credential Verification Fix Tencent Cloud WAF custom rules not working

Fix Tencent Cloud WAF Custom Rules Not Working (and the operational gotchas around account, risk control, and renewals)

Tencent Cloud Business Credential Verification You searched “Tencent Cloud WAF custom rules not working” because your expectation is simple: you created a custom rule, you saw it in the console, you expected it to block/allow specific requests, but nothing happened—or it worked for 5 minutes then stopped. This article focuses on the fixes that actually resolve the situation in real tenant environments, including the less obvious parts: account verification state, risk-control review outcomes, and whether your payment/renewal status caused rule enforcement to pause.

First: confirm which “not working” you’re dealing with

Before troubleshooting settings, identify the failure mode. The remediation differs depending on whether Tencent is not applying your rule at all, or the rule is applied but not matching traffic, or matching but not taking the expected action.

Symptom A: Your rule shows “Enabled”, but logs show no matches

Usually this is a match-condition problem (field mismatch, encoding, header name case, or request path normalization), or the rule is bound to the wrong asset (domain/instance) / traffic direction (client vs. origin). Less commonly, enforcement is blocked by account/risk controls.

Symptom B: Logs show matches, but action is not what you expect

Common causes: policy priority overrides, rule scope mismatch (e.g., “only this path prefix” vs. “this exact path”), or another rule fires earlier in the chain and decides allow/deny first.

Symptom C: It worked briefly, then stopped after changes

This often happens after you edited rule priority/order, updated the domain binding, switched WAF instance/region, or made a change that triggered risk controls or configuration propagation delay.

Operational checklist: verify enforcement scope before touching matching logic

If you’re fixing WAF custom rules on a real production domain, don’t start with regex. Do a scope sanity check first—this prevents hours of wasted testing.

1) Validate the domain/asset binding is the same one receiving traffic

• Confirm the WAF instance you configured is bound to the exact domain (and protocol) you’re testing. In multi-domain setups, people often edit a WAF rule for example.com but test www.example.com (or vice versa).
• If your site uses redirects or a CDN layer, ensure your test hits the same “entry” that WAF is inspecting. Otherwise your request may bypass WAF inspection at the edge you think you’re using.

2) Confirm your traffic is actually passing through WAF at this moment

• Use the WAF request log (or equivalent “security events” view) to confirm any requests appear. If no traffic appears, your configuration scope or binding is wrong—or enforcement is paused.
• Check whether you’re testing with a cached response from your CDN/origin. A “200 OK from cache” can trick you into believing the rule didn’t match.

3) Check rule priority and conflicting policies

Tencent WAF evaluates rules in an order; higher-priority policies (or preset rules) may short-circuit your custom rule. If your goal is “block these URLs,” but a higher-priority allow policy exists, your rule will appear “broken.”

• Temporarily lower the threshold: set action to alert or count only first, then switch to block once you see matches.
• If the preset policy set is active (common in managed security baselines), compare your rule’s action with baseline behavior.

Matching logic fixes that solve most “custom rule not working” cases

After scope and priority checks, the remaining root causes are usually in matching logic details: field selection, encoding, and exactness. Here are fixes I’ve used in real troubleshooting with Tencent Cloud WAF custom rules.

Use the correct request field (path vs. URI vs. query vs. header)

In WAF consoles, rule conditions often include choices like: path, request URI, query string, cookie, user-agent, specific headers, or combined fields. A mismatch here makes the rule “look correct” but never match.

• If you want to match “/login?redirect=…”, confirm you’re using the query field as part of the condition. Matching only the path (e.g., “/login”) will miss when your intention depends on query.
• If you match headers, ensure the header name is the one actually received after any proxy/CDN normalization.

Handle URL encoding and double-encoding

Attack payloads often arrive URL-encoded or even double-encoded by clients or WAF bypass attempts. If your custom rule expects a literal string, it may fail.

• Test with the exact raw request that reaches WAF (from logs or a controlled client that disables encoding).
• If Tencent’s condition supports “decode before match” (wording varies by console), enable it to normalize encoded characters before evaluation.

Be careful with leading slashes and exact vs. prefix matching

“/api/login” vs. “api/login” matters. Also “startsWith” and “contains” behave very differently for paths with parameters.

• If you’re blocking a family of URLs, prefer prefix or contains matching (e.g., /api/ prefix).
• If you need to block one exact endpoint, use exact match and include the method if supported.

Header-based rules: confirm actual header casing and presence

Some environments rewrite headers (especially through CDNs or application gateways). People frequently create a rule for User-Agent but the incoming header differs or is stripped.

• Validate header presence by comparing your test request with what WAF log shows (or by capturing at the edge with debug headers).
• For “Authorization” rules, confirm whether the rule condition expects the entire value or a token substring.

When configuration is correct but enforcement still doesn’t happen: risk control and account state

Here’s the part many people miss: sometimes WAF rules are created fine, but enforcement is delayed or restricted due to account verification and risk-control state. This matters more if you purchased/activated your Tencent Cloud account recently, or you are using an account purchased through a third party (common in “cheap cloud” markets).

Tencent Cloud Business Credential Verification Check your Tencent Cloud account verification (KYC) status

If your account is in a partially verified state, some security product capabilities may behave inconsistently. In practice, I’ve seen scenarios where:

• WAF policy can be created but enforcement/log retention behaves oddly.
• Certain management actions are blocked or require additional verification.

What to do: open your console’s identity verification center and confirm that the account is fully verified for commercial use. If you changed account type recently (e.g., from individual to enterprise), re-check permissions.

Risk control review outcomes can affect “rule execution” pathways

Tencent Cloud applies risk control at multiple stages: account registration, funding, service activation, and sometimes after unusual usage patterns.

Common real-world triggers that lead to enforcement inconsistency:

• Sudden burst of WAF policy changes and test traffic from multiple IPs/VPS in a short window.
• Frequent switching between regions/instances tied to the same domain.
• Account tied to previously flagged billing behavior (especially with imported/bought accounts).

Mitigation: run a short, controlled test (single region, stable source IP for 10–15 minutes), then re-check WAF event logs for matches and final action. Avoid making multiple config edits during that window.

Tencent Cloud Business Credential Verification Usage restrictions after account status changes

If you recently topped up, renewed, or changed your billing method, you might have a brief restriction period. Additionally, if a subscription lapses (or a security service is not renewed), you can still see old rules in the UI but they won’t enforce.

Payment method and renewal realities that can cause “WAF rules not working”

Tencent Cloud Business Credential Verification This is usually the culprit in “it worked yesterday then stopped” incidents. Tencent WAF in some setups depends on the overall service activation/billing state of the security product instance.

Tencent Cloud Business Credential Verification Scenario: prepaid/annual security service expires, rules remain visible

The console often still shows your policies, but the enforcement path is not active. You’ll see no matches (Symptom A) because WAF may not be fully running.

Tencent Cloud Business Credential Verification Action: check:

• WAF instance service status (active/suspended/expired)
• Tencent Cloud Business Credential Verification Billing center for the specific product line
• Any outstanding payment failure notices

Payment method differences: what changes operationally

People ask “what payment method is safest?” The practical answer: choose the method that gives you stable renewal automation and fewer failure modes.

Account purchasing and KYC: how it relates to WAF rule enforcement problems

If you bought a Tencent Cloud account to get WAF faster (common when people try to avoid registration time), your risk increases in two ways: (1) verification/ownership issues, and (2) risk-control flags that can restrict security features.

What to check before you “invest time” configuring WAF

• Legal ownership: the account should be under your own identity or properly transferred to your entity. If the account is still linked to a prior owner’s verification, you may face future restrictions.
• Verification completeness: ensure KYC isn’t in a pending or “needs additional info” state.
• Billing stability: confirm auto-renew is enabled and payment method is stable.
• Risk-control flags: if the account has unusual behavior history, expect inconsistent enforcement during reviews.

Common failure pattern after purchasing an account

The user creates a custom rule, sees matches in early tests, then later the enforcement stops. This often aligns with a risk-control review or a billing interruption rather than a rule error.

Troubleshooting playbook (use this order to minimize time)

Step 1: Reproduce with a minimal, deterministic test request

• Pick one endpoint and one payload.
• Use a stable client IP and a test method (GET/POST) that your rule targets.
• Include a unique marker parameter so you can search logs quickly.

Step 2: Verify you’re seeing WAF traffic in logs

• If logs show nothing: focus on scope/binding/enforcement status (not match logic).
• If logs show matches: focus on priority/action outcomes.

Step 3: Temporarily switch action to “alert/count”

This reduces the chance that a different control blocks your request before your intended rule evaluates. Once you confirm match accuracy, switch to block.

Step 4: Eliminate encoding and field selection uncertainty

• Test both encoded and decoded strings.
• Try matching on the most stable field (often path + exact prefix) before going deep into headers.

Step 5: Check priority conflicts

If your rule matches but does nothing, you likely hit a higher-priority rule. Reorder priorities or narrow your condition to avoid overlaps.

Step 6: Check account verification and billing state

• Confirm KYC is verified.
• Confirm WAF instance/billing status is active.
• Look for payment failure notifications and renewal deadlines.

Cost comparison and decision points (what to choose while fixing the rule)

When custom rules don’t work, teams often consider switching WAF modes or altering protection scope. That can change cost, but the bigger issue is operational risk (more changes while you’re already troubleshooting).

Keep scope narrow first to control debugging cost

• Use a test domain/subdomain to validate rule matching before applying to all production assets. This avoids paying for broad enforcement and reduces log noise.
• Don’t enable multiple complex rules at once. Cost and troubleshooting complexity both increase.

When to spend time vs. when to escalate

If you’ve confirmed:

• binding is correct,
• logs show matches,
• priority doesn’t conflict,
• account verification and billing are active,
• and the action still doesn’t apply,

then you’re no longer in “rule syntax troubleshooting.” It’s time to escalate with Tencent support and include: timestamps, request samples, rule IDs, and the expected action vs observed logs.

FAQ (the questions you probably care about right now)

1) Why does the rule show “created/enabled” but no requests match?

The top 3 reasons I see in real cases: wrong asset binding (domain/protocol mismatch), incorrect field selection (path vs URI vs query vs header), or encoding mismatch. Only after those should you suspect account/billing/risk control.

2) I changed the rule priority—why is it still not blocking?

Priority changes can take propagation time. Also, another preset or baseline policy may have higher precedence. Check logs for which rule ID triggered; don’t assume your rule was evaluated.

3) Can KYC/billing status prevent WAF custom rules from enforcing?

Tencent Cloud Business Credential Verification Yes indirectly. If the WAF instance is effectively suspended due to billing or restricted due to verification/risk controls, the UI may still show policies. Enforcement/log patterns become inconsistent. Always confirm “service active” and KYC status.

4) I used a recently purchased Tencent Cloud account—what should I do before configuring WAF?

Confirm account identity verification is complete under the current entity/owner, and ensure billing is stable with auto-renew. Also, avoid rapidly changing many security policies during the first day—this can trigger risk-control review.

5) What payment method is safest for long-running WAF enforcement?

In practice: prepaid/annual with stable auto-renew and notifications. Pay-as-you-go can work well, but budget/funding issues can cause sudden service suspensions. Whatever you choose, test a “grace period” by checking service status before due dates.

6) Why did it work earlier and then stop?

Most common: billing renewal failed or lapsed, or a risk-control review temporarily impacted enforcement pathways. Second: rule scope changed (domain binding or instance). Third: conflicting policies added later.

Quick “most likely” fix map

What I need from you to pinpoint the exact cause (optional, but useful)

If you want a precise diagnosis, paste (redact sensitive tokens):

• Rule type and condition fields you used (path/URI/query/header/etc.)
• Expected action (block/allow/count) and what you observed
• Whether WAF logs show matches; if yes, the triggered rule ID/time
• Domain/protocol and which WAF instance you edited
• Your account KYC status (verified/pending) and whether renewal recently occurred