Website Hijacking Redirects: Distinguishing and Troubleshooting DNS, JS, and Server Configuration Causes

“My website redirects to another site when I open it.” — This phenomenon can stem from three completely different causes, with troubleshooting directions and handling methods that do not overlap. Determine the cause first, then take action; otherwise, you might find yourself “changing DNS settings but the problem persists because it wasn’t a DNS issue in the first place.”

Three Types of Causes

First Minute: Distinguish Using curl

# Check if the server directly returns a redirect
curl -I https://example.com/ | head -5
curl -sIL https://example.com/ | grep -iE 'HTTP/|location'

Judgment criteria:

• If the response headers contain Location → The server is redirecting, indicating a configuration layer or backdoor issue
• If the response is 200, but the page contains redirect scripts → JS layer
• If connection fails / resolves to an unknown IP → DNS layer

DNS Layer: Multi-location Resolution Comparison

# Local resolution result
dig +short example.com A

# Compare using public DNS servers
dig @8.8.8.8          example.com +short
dig @114.114.114.114  example.com +short
dig @223.5.5.5        example.com +short

# Check authoritative DNS answers (bypassing cache)
dig +trace example.com A

# Confirm who the authoritative NS is (check if it has been changed)
dig example.com NS +short

Key judgment criterion: If multiple DNS servers return inconsistent results, or the resolved IP is not your server, it is a DNS layer issue.

# Confirm if the resolved IP belongs to your server
dig +short example.com A
# Use this IP to verify in the cloud console, or directly:
curl -I -H 'Host: example.com' http://resolved_IP/

Also check one more thing: Whether the DNS servers (NS) in your domain registrar’s backend have been changed. Changing NS records has a broader impact than changing individual records and is often overlooked.

JS Layer: Triggered on Demand, Hardest to Self-Diagnose

# Fetch page source and look for suspicious scripts
curl -s https://example.com/ | grep -iE '<script|iframe|document.write|window.location'

# Look for unfamiliar external script domains
curl -s https://example.com/ | grep -oE 'src="https?://[^"]+"' | sort -u

Typical conditional hijacking looks like this — redirects only under specific conditions:

<script>
// Redirect only when coming from search engines
if (document.referrer && document.referrer.indexOf('baidu') > -1) {
    window.location.href = 'http://external_address';
}
// Or redirect only on mobile devices
if (/Android|iPhone/.test(navigator.userAgent)) {
    window.location.href = 'http://external_address';
}
</script>

This is why your own visits always appear normal — you do not meet the trigger conditions. Verification method:

# Simulate search engine referral
curl -s -H 'Referer: https://www.baidu.com/' https://example.com/ | grep -i 'window.location'

# Simulate mobile User-Agent
curl -s -A 'Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)' 
  https://example.com/ | grep -i 'window.location'

Injection points are usually in these areas:

• Theme template files (header.php / footer.php)
• Database content (WordPress wp_posts)
• Site-wide custom code / widgets

# Search template files
grep -rEln 'window.location|document.write' /var/www/html/ --include='*.php' --include='*.js'

# Search database content (WordPress)
mysql -e "SELECT ID, post_title FROM wp_posts
          WHERE post_content LIKE '%window.location%'
             OR post_content LIKE '%<script%';" dbname

Server Configuration Layer

# ① Find redirect rules
grep -rniE 'return 301|return 302|rewrite.*redirect|proxy_pass' 
  /etc/nginx/ | grep -v 'ssl|fastcgi'

# ② Find .htaccess (Apache)
cat /var/www/html/.htaccess

# ③ Find auto-loading (commonly used by backdoors, easily missed)
cat /var/www/html/.user.ini
find /var/www -name '.user.ini' -exec cat {} ;

# ④ Redirects within the application
grep -rn "header('Location'|header("Location" /var/www/html/ --include='*.php' | head

If the redirect rule was not configured by you, treat it as a security breach: check for backdoors, scheduled tasks, and compromised accounts, rather than just deleting that line — it will come back.

Decision Tree

Website Redirected
├─ curl -I Response Header Contains Location
│  └─ Server-side Redirect → grep config for 301/rewrite
│     ├─ Configured by you     → Modify configuration
│     └─ Not configured by you → Treat as intrusion: check backdoors/scheduled tasks/accounts
├─ Response 200
│  ├─ Suspicious script in source
│  │  ├─ With conditional logic      → JS hijacking, simulate Referer/UA to reproduce
│  │  └─ Unconditional redirect      → Direct redirect script
│  └─ Clean source, but still redirects when accessed
│     └─ Likely cached/CDN serving old content → Clear cache and test again
└─ Connection Failed / Resolution Anomaly
   └─ DNS Layer → Multi-location dig comparison + check registrar NS changes

Scenario Walkthrough: Accessing Your Domain Redirects to an Unknown Site

Phenomenon: Users report that accessing the domain redirects to an unrelated site, and the behavior is unstable — sometimes it happens, sometimes it doesn’t; switching networks yields different results.

1. Use the “instability” characteristic to determine the troubleshooting direction → Stable redirects usually come from server-side logic, whereas intermittent redirects varying by region/network are more likely caused by the resolution process.
2. Compare resolution results across different networks → Some networks resolve to target addresses inconsistent with expectations.
3. Check if records at the domain management authority have been altered → Discover that the authoritative servers used for domain resolution point to a set not belonging to you.
4. Trace the source of changes → Credentials for the domain registrar account were leaked, leading to record modifications.
   This step is crucial: without blocking the source, reverting the changes will result in them being modified again.
5. Simultaneously rule out the other two possibilities → Check if there are redirect scripts in page files or injected redirect code in the database; these causes present similar symptoms but require completely different handling.
6. Regain control and harden security → Change registrar account passwords, enable two-factor authentication,
   and after reverting authoritative servers to correct values, verify across networks one by one.

# Compare results from different public DNS — inconsistency is a key signal of resolution layer issues
for d in 223.5.5.5 119.29.29.29 8.8.8.8; do
  echo "--- $d"; dig example.com A @$d +short
done

# Check if the current authoritative server for the domain is yours
dig example.com NS +short

# Rule out server-side causes: check for redirect scripts in pages
curl -s https://example.com/ | grep -oE 'location.(href|replace)|window.open' | head
grep -rIn 'http-equiv=.refresh' /website_directory | head

Root Cause: Credential leakage on the domain management side led to resolution records being redirected elsewhere.
The server itself had no issues, so searching the server would yield no results.

Two Key Takeaways:

• If redirects are intermittent and vary by region, your first reaction should be to check resolution, not to inspect website programs.
  This distribution characteristic points directly to the resolution layer, saving significant time on ineffective server-side troubleshooting.
• Block the change source before fixing.
  Simply reverting records without addressing the leaked account allows attackers to modify them again at any time.

8 Common Pitfalls

1. Taking action without distinguishing the cause: One curl -I command can categorize the issue.
2. Relying solely on browser self-checks: Conditional hijacking won’t trigger for you.
3. Only checking nginx configuration: Hidden in .user.ini, .htaccess, or the database.
4. Deleting redirect rules and calling it done: If not configured by you, it indicates an intrusion; you must find the entry point.
5. Ignoring the DNS layer: Multi-location resolution comparison is mandatory.
6. Forgetting to check registrar NS: NS changes have a broader impact.
7. Clearing cache but not verifying: CDN may still serve old content, leading to false assumptions that the fix failed.
8. Failing to re-verify: Check again the next day to confirm the issue hasn’t recurred.

Real Customer Feedback (From Cloud Market Reviews and Inquiries for Similar Products)

The following excerpts are taken from real buyer reviews and inquiries for similar operations and maintenance services on Alibaba Cloud / Tencent Cloud / Huawei Cloud Cloud Markets (service providers include our store and competitors, provided here for reference only, not fictional tickets from this site):

1****1 Rating: 5.0 Points 2020-06-18 11:50 1****1 Rating: 5.0 Points 2020-04-26 18:46 1****1 Rating: 5.0 Points 2020-04-26 18:45 1****1 Rating: 5.0 Points 2020-04-26 18:45 1****1 Rating: 5.0 Points 2020-04-26 18:45 1****1 Rating: 5.0 Points 2020-04-26 18:44 He**** She Rating: 5.0 Points 2019-09-26 09:47

1****8 Rating: 5.0 Points 2019-10-29 22:35 Good 1