Adsterra Removed a Month Ago, OnePlus Browser Still Flags Site as Risky: Full Domain Unblocked Across Multiple Platforms

In a previous article, I documented an issue with abnormal website redirects caused by third-party ads.

The site had integrated Adsterra at the time. Later, while testing on mobile, I noticed that pages were triggering abnormal cross-domain redirects and exhibiting behaviors that my site clearly should not have been causing. After troubleshooting, I ultimately removed the ad code and stopped using that type of advertising.

I originally thought the problem would end there.

Once the ad code was removed, the site returned to normal. Given enough time, various security systems should re-crawl the site and gradually clear the previous risk assessments.

But that was not the case.

By September 2026, nearly a month after the original issue, I accessed the site again using the built-in OnePlus browser and still saw:

Website has security risks
Malicious redirect blocked

Sometimes it would directly show:

This page may contain illegal information

This made me realize something:

Just because a website is currently clean does not mean the “risk reputation records” left by various platforms will automatically disappear.

So I began a fairly comprehensive round of URL security status checks.

---

1. First confirm: Is the website actually still compromised, or has OnePlus simply not updated its historical risk flag?

Initially, the most important thing was not to rush into an appeal.

If the site itself still had malicious code, redirects, or third-party script issues, simply asking the browser to lift the warning would be pointless.

So I cross-checked it on several different security platforms first.

Google Safe Browsing: No unsafe content found

Google’s Safe Browsing diagnostic result showed:

No unsafe content found

Moreover, the information update time displayed on the page had already reached September 10, 2026.

This meant it was not a cached result from several months ago.

Tencent Cloud URL detection: No risk found

I then used Tencent Cloud Mobile Security’s URL detection.

The result was also normal:

No risk found at this time

Google Search Console: No security issues

Since the site was already integrated with Google Search Console, I also checked:

Security & Manual Actions → Security issues

The result was:

No issues detected

At this point, at least both the Google and Tencent systems did not consider the site to have any obvious current risks.

---

2. Continue cross-validation with multiple security engines

To rule out the possibility that “Google simply hadn’t found it,” I continued using several third-party aggregate detection services.

URLVoid: 0 / 36

URLVoid’s detection result was:

0 / 36

This means that out of the 36 security sources involved in the check, not a single one had blacklisted the current domain.

Sucuri: No malware, and not blacklisted

Sucuri SiteCheck provided two core results:

No Malware Found
Site is not Blacklisted

In other words, it did not scan any malware, and the site was not found in any of the multiple blacklists it checked.

Combining these results, the situation was becoming increasingly clear:

At least according to multiple publicly queryable security systems, the website had returned to normal.

But the OnePlus browser continued to block it.

---

3. Baidu URL Security Center, however, retained a historical risk record

There was another rather interesting finding during this troubleshooting process.

Baidu URL Security Center still displayed the website as:

Dangerous

And the risk record on the right clearly showed:

2026-08-08
Dangerous, the website’s web pages contain illegal information!

This date is highly noteworthy.

Because it basically aligns with the time I was dealing with the Adsterra abnormal redirects.

More interestingly, further down on the same Baidu detection page, the “Recent site security status” for:

• Fraudulent website monitoring
• Hacked or malicious website monitoring
• Illegal content website monitoring
• Tampering monitoring

all showed:

Safe

This looks like a typical state:

The current scan shows no problems, but the previously left risk record has not yet been cleared.

However, when actually opening the website in the Baidu App, no risk warning popped up, nor did it block access.

So I did not prioritize dealing with Baidu at the time.

What actually affected user access was still the OnePlus / ColorOS browser.

---

4. The OnePlus browser actually provides instructions for handling “wrongly blocked websites”

Initially, I couldn’t find an obvious “webmaster appeal” button on the browser’s risk warning page.

There was a “Report” option in the menu, but its categories were:

• Pornography
• Gambling
• Fraud
• Harassment
• Phishing and account theft
• Other

This was clearly meant for reporting bad websites, not for webmasters to clear false positives.

So I didn’t hastily submit it via “Report → Other”.

Later, I found a genuinely useful sentence in the OnePlus browser’s help page:

If you find a website has been wrongly blocked, please send the URL link to online customer service to explain the situation. We will verify it and unblock the website if it was a false block.

This made it clear:

The correct entry point is not “Report”, but contacting customer service.

---

5. The first appeal succeeded, but only unblocked www

Contacting online customer service was not exactly smooth.

Initially, I was connected to an AI assistant, and some of the menu paths it provided didn’t even match the actual browser interface.

I eventually reached a human agent through the “Not helpful” options.

The human agent collected information including:

• Phone model
• System version
• Browser version
• URL where the problem occurred
• Screenshot of the risk warning

and other details.

The agent then stated that a customer service manager would call back to handle it.

A few days later, I received a notification:

The problem has been resolved.

I immediately tested:

www.shuijingwanwq.com

Sure enough, it opened normally, and the security risk warning no longer popped up.

But then the next problem arose.

I continued to access:

• en.shuijingwanwq.com
• go-dev.shuijingwanwq.com
• ja-go-dev.shuijingwanwq.com

These subdomains still showed:

This page may contain illegal information

In other words, the first round of handling actually only resolved:

www.shuijingwanwq.com

rather than the entire:

shuijingwanwq.com

domain system.

---

6. Why unblocking just one www doesn’t truly solve the problem

If my site only had a single www, this might have been enough.

In reality, I have been using multiple subdomains to host different projects, such as the English site, a Go multilingual project, and potentially other independent services in the future.

The real question, therefore, was not:

Can go-dev be added to the whitelist again?

but rather:

Why do normal subdomains under the same root domain still inherit the previously left risk status?

If it can only be handled one hostname at a time, then today I submit:

en.shuijingwanwq.com

go-dev.shuijingwanwq.com

ja-go-dev.shuijingwanwq.com

If I add a new subdomain later, will I have to manually appeal again?

This is clearly not a real solution.

So when I contacted customer service the second time, I explicitly stated:

I hope the URL security team will conduct a comprehensive review of the root domain shuijingwanwq.com and its related subdomains, rather than just handling a single www hostname.

If the security system technically can only handle things by hostname, I also hoped they would at least clarify:

Will newly created subdomains still inherit the current historical risk flag?

This time, the human agent said they would immediately escalate the feedback, and a customer service manager would continue to follow up.

---

7. Second round of handling: Customer service first notifies that the technical team has completed processing

On September 18, 2026, the Huanmei customer service called again.

The agent told me that the technical team had processed this issue.

However, the security status update wouldn’t necessarily sync everywhere immediately, and it might take up to about 4 days to fully take effect.

This call was important because it meant the second submission regarding the “entire root domain and subdomain system” had actually entered the technical team’s processing and completed backend operations, rather than just staying at the customer service logging stage.

After receiving the call, I picked up the OnePlus phone again and tested the subdomains that previously still showed risk warnings one by one.

---

8. Retesting myself: Most subdomains have returned to normal

After retesting, the changes were already very obvious.

Previously, multiple subdomains including:

en.shuijingwanwq.com

go-dev.shuijingwanwq.com

ja-go-dev.shuijingwanwq.com

would trigger security warnings like “This page may contain illegal information”.

When testing them again this time, most of the domains were able to open normally, and the previous risk blocking pages no longer appeared.

For example, the Go language tour multilingual project could be accessed directly and normally.

There were still a few domains that hadn’t fully recovered at the time.

However, the agent had explained on the phone beforehand that after backend processing was complete, syncing the relevant security data could take up to about 4 days. Therefore, combined with the result that “most domains had recovered,” it could be basically confirmed:

The second round of processing for the entire domain system had taken effect, and the remainder was mainly a sync time issue.

This was clearly different from the first time, where only www.shuijingwanwq.com had recovered.

---

9. A fixed website does not mean its reputation is automatically fixed

This experience made me truly distinguish between two concepts:

Website security status and website security reputation.

The abnormal redirects caused by Adsterra were an actual problem the website had.

After removing the related ad code:

• The abnormal redirects disappeared;
• Google Safe Browsing was normal;
• Google Search Console had no security issues;
• Tencent URL detection was normal;
• URLVoid was 0/36;
• Sucuri detected no malware and found no blacklist records.

As far as the website itself was concerned, the problem had been solved long ago.

But the historical risk records saved by some URL security systems do not automatically disappear just because the code was deleted.

This is why, a month later, I could still see in the OnePlus browser:

Website has security risks

And even:

This page may contain illegal information

Therefore, if I encounter similar problems in the future, I will split the recovery process into two phases.

The first phase is to fix the actual website problem: remove malicious code, abnormal ads, redirect scripts, or other risk sources.

The second phase is to restore the website’s reputation: check whether browsers, security vendors, and URL reputation databases still retain historical risk records.

Only when both steps are complete is it truly considered restored to normal.

---

10. Another easily overlooked issue: Don’t just focus on www during an appeal

There was another valuable lesson from the first round of handling.

The URL initially submitted to OnePlus customer service was mainly:

https://www.shuijingwanwq.com

The technical team did successfully clear the risk warning for this hostname.

The problem was, after www recovered:

en.shuijingwanwq.com

go-dev.shuijingwanwq.com

ja-go-dev.shuijingwanwq.com

and other subdomains were still being blocked.

This shows that, at least during this actual handling process, a hostname having its risk cleared does not mean that all subdomains under the same root domain will automatically sync and recover.

For webmasters with only a single www website, this might not matter.

But if multiple websites, projects, or services are running long-term under one root domain, it’s best to explain this situation clearly right from the start of the appeal:

I hope a comprehensive review will be conducted for the root domain and its normal subdomains, rather than just handling the single submitted hostname.

This is also why, after contacting customer service the second time, I didn’t just continue to simply list a few addresses, but explicitly requested to handle:

shuijingwanwq.com

and the entire normal subdomain system under it.

Ultimately, after this round of processing, most subdomains recovered together.

---

11. Finally

This whole matter dragged on for over a month.

The real problem at the beginning was abnormal redirects caused by third-party ads.

Later, the ad code was removed, and the website itself had long since returned to normal. I originally thought that if I just waited a while, the risk warnings would naturally disappear after each platform re-detected the site.

Facts proved that this was not necessarily the case.

Google, Tencent, and multiple third-party security platforms had long since shown normal results, but the OnePlus browser still retained its historical risk assessment.

After contacting customer service the first time, www was successfully restored, and for a time I thought the matter was over.

It was only upon further testing that I discovered other subdomains still had issues.

So I made a second round of feedback, this time explicitly stating the need to re-evaluate things from the perspective of the entire root domain system.

It wasn’t until September 18 that Huanmei customer service notified me that the technical team had completed processing. I subsequently tested it myself, and most of the previously blocked subdomains had returned to normal; the few remaining addresses just needed to wait for security data to sync.

The deepest lesson this whole experience left me with boils down to a single sentence:

Removing risky code only means the website’s problem is fixed; it does not mean the historical security reputation records have also disappeared.

If the actual risk has been completely eliminated, yet a certain browser still blocks it weeks later, there is no need to wait indefinitely for so-called “automatic re-detection”.

After confirming that other security platforms are normal, proactively contacting the corresponding platform to request a recheck and the removal of historical risk flags is often the real solution.

系列导航