Con số 1 trên 4: chỉ một trong bốn phép thử curl trên máy chủ thử lộ chuyển hướng lạ, đó là phép điện thoại đến từ Google

Website chuyển hướng lạ trên điện thoại mà bạn không thấy là do mã ẩn chỉ chạy khi khách khớp một điều kiện: dùng điện thoại, đến từ Google, vào lần đầu, chưa đăng nhập. Muốn tái hiện, bạn phải thử đủ tổ hợp thiết bị và nguồn truy cập, không chỉ một. Trên máy chủ thử Net Solutions dựng, 3/4 phép thử trả trang bình thường; chỉ phép “điện thoại, đến từ Google” bị đẩy sang trang lạ.

Bạn không thấy vì mã chỉ chạy với một nhóm khách

Khách báo “vào bị đẩy sang trang khác” còn bạn mở lên vẫn bình thường. Hai bên đều nói thật. Mã chuyển hướng ẩn được viết để bỏ qua đúng những người hay kiểm tra: chủ web, quản trị viên, công cụ quét.

Hai tài liệu bảo mật về chuyển hướng WordPress mô tả cùng một kiểu. Patchstack nêu các mã hiển thị trang sạch cho người dùng máy tính trong khi nhắm vào khách di động, và dùng nhận diện user-agent để tránh công cụ quét. Bài của Fat Lab Web Support nói thêm: mã có thể xét loại thiết bị, nguồn truy cập hoặc tình trạng đăng nhập, nên quản trị viên không thấy lỗi khi đang đăng nhập.

Hệ quả thực tế: bạn mở trang bằng máy tính, đã đăng nhập, gõ thẳng địa chỉ. Cả ba thói quen này đều nằm ngoài vùng mã nhắm tới. Phép thử của bạn “sạch” không vì site sạch mà vì bạn không thuộc nhóm bị nhắm.

Ví dụ đã đo: chúng tôi dựng một máy chủ thử (mô phỏng, không phải ca của khách) chỉ chuyển hướng khi User-Agent có chữ “Mobile” và Referer có “google.”. Thử bốn tổ hợp, 3 tổ hợp trả trang thật, chỉ tổ hợp thứ tư lộ. Nếu dừng sau phép thử đầu tiên, bạn kết luận sai. Dấu hiệu chung của một site bị xâm nhập xem thêm ở bài website bị hack: dấu hiệu nhận biết.

Bốn điều kiện kích hoạt hay gặp

Mã chuyển hướng có điều kiện thường kiểm một hoặc nhiều thứ trong bảng sau. Mỗi điều kiện có một cách thử riêng, và bạn cần thử từng cái.

Điều kiện Mã kiểm tra gì Vì sao hay dùng Cách thử
Thiết bị User-Agent có “Mobile”, “Android”, “iPhone” Chủ web thường kiểm trên máy tính Điện thoại thật, hoặc curl đổi -A
Nguồn đến Referer có google, bing Khách gõ thẳng địa chỉ thì không bị đẩy Đi từ kết quả Google thật, hoặc curl thêm -e
Khách lần đầu Chưa có cookie; chuyển hướng một lần rồi đặt cookie Lần thứ hai bạn mở lại thì hết lỗi Tab ẩn danh, mạng khác, xoá cookie
Chưa đăng nhập Bỏ qua người có cookie quản trị Quản trị viên không bao giờ thấy lỗi Thoát tài khoản trước khi thử

Tổng hợp từ Patchstack (bài về WordPress redirect hack) và Fat Lab Web Support, đọc ngày 22/10/2026.

Google xếp kiểu này vào spam. Trong chính sách spam, mục “Sneaky redirects” liệt kê đúng tình huống bạn đang gặp:

Cho người dùng trên máy tính thấy một trang bình thường trong khi chuyển hướng người dùng trên thiết bị di động đến một miền không liên quan và khác hoàn toàn.

— Chính sách spam của Google Search (bản tiếng Việt), mục Chuyển hướng lén lút (Sneaky redirects), đọc 24/10/2026

Trang chính sách spam của Google Search bản tiếng Việt, mục Chuyển hướng lén lút, nêu ví dụ chuyển hướng người dùng điện thoại sang miền không liên quan
Mục Chuyển hướng lén lút (Sneaky redirects) trong chính sách spam của Google Search, chụp ngày 24/10/2026.

Cũng trong mục đó, Google ghi rõ có nhiều lý do hợp lệ để chuyển hướng một URL sang URL khác, như đổi địa chỉ site hay gộp nhiều trang thành một. Chuyển hướng tự nó không xấu. Điều xấu là khách bị đưa tới nơi họ không muốn tới. Phần 6 bên dưới nói cách tách hai trường hợp.

Tái hiện bằng curl: thử đủ bốn tổ hợp

curl cho bạn đổi User-Agent và Referer bằng một dòng lệnh, nên tái hiện được mà không cần điện thoại. Lệnh dưới chạy được trên Windows; trên macOS hoặc Linux đổi NUL thành /dev/null. Trong PowerShell hãy gõ curl.exe, vì curl ở đó là bí danh của lệnh khác.

curl · tái hiện bốn tổ hợp
curl -s -o NUL -L -A "<User-Agent>" -e "<Referer>" -w "%{http_code} chuyen=%{num_redirects} cuoi=%{url_effective}" https://ten-mien-cua-ban.vn/

# Máy tính, vào thẳng      : -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36"        (bỏ -e)
# Android, vào thẳng       : -A "Mozilla/5.0 (Linux; Android 14; Pixel 8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Mobile Safari/537.36"                   (bỏ -e)
# Googlebot di động        : -A "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"   (bỏ -e)
# Android, đến từ Google   : -A "Mozilla/5.0 (Linux; Android 14; Pixel 8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Mobile Safari/537.36" -e "https://www.google.com/"

Ba thông số cần đọc. http_code cho biết trang trả về thế nào. num_redirects đếm số lần bị đẩy đi. url_effective là địa chỉ cuối cùng curl đứng. Chỉ cần chuyen lớn hơn 0 và địa chỉ cuối khác trang bạn gõ là đã có dấu hiệu.

Chúng tôi chạy đúng bốn lệnh đó vào hai nơi lúc 24/10/2026 07:10: máy chủ thử (mô phỏng, chạy trên localhost) và netsolutions.vn.

Tổ hợp thử Máy chủ thử (mô phỏng) netsolutions.vn
Máy tính, vào thẳng 200 · 0 lần chuyển 200 · 0 lần chuyển
Android, vào thẳng 200 · 0 lần chuyển 200 · 0 lần chuyển
Googlebot di động, vào thẳng 200 · 0 lần chuyển 200 · 0 lần chuyển
Android, đến từ kết quả Google 200 · 1 lần chuyển → /trang-la 200 · 0 lần chuyển

Số đo của Net Solutions, 24/10/2026 07:10, lệnh curl -L. Máy chủ thử chuyển hướng khi User-Agent có “Mobile” và Referer có “google.”.

Đọc bảng: netsolutions.vn trả 4/4 phép thử bình thường, không lần chuyển hướng nào. Đó là hình dạng của một kết quả sạch ở bốn tổ hợp này. Máy chủ thử cũng cho 3/4 phép sạch, nhưng phép thứ tư lộ ra một lần chuyển hướng sang một trang khác. Một kết quả sạch chưa chứng minh gì.

Sạch chưa phải là site sạchMã có thể nhận ra công cụ kiểm tra, dải IP của máy quét hoặc vị trí địa lý và trả trang sạch cho chúng. Bốn phép thử sạch nghĩa là “chưa thấy”, không phải “không có”. Hãy làm tiếp bước điện thoại thật.

Tái hiện trên điện thoại thật, đi từ Google

Điện thoại thật vượt được những gì curl bỏ sót: mạng nhà mạng, cookie sạch, và đường đi qua Google. Làm đúng thứ tự sau.

  1. Tắt Wi-Fi, dùng 4G hoặc 5G để IP và vị trí khác với lúc bạn quản trị website.
  2. Mở tab ẩn danh để không mang cookie và không còn phiên đăng nhập.
  3. Vào Google, gõ tên miền hoặc từ khoá mà khách hay dùng, rồi bấm vào kết quả của bạn.
  4. Quay video màn hình từ lúc bấm. Video là bằng chứng để gửi bên hosting hoặc bên xử lý.
Dùng 4G và đi từ kết quả GoogleGõ thẳng địa chỉ vào thanh trình duyệt sẽ làm mất Referer. Nhiều mã chỉ kích hoạt khi khách đến từ kết quả tìm kiếm, nên bấm từ trang kết quả Google là bước quan trọng nhất.

Nếu chỉ có máy tính, bạn có thể giả lập điện thoại bằng chế độ thiết bị trong Chrome DevTools. Công cụ này hữu ích nhưng có giới hạn mà chính Google nêu:

Hãy xem chế độ thiết bị như một phép xấp xỉ bậc nhất về cách trang hiển thị và cảm nhận trên thiết bị di động. (dịch)

— Chrome for Developers, Device Mode, đọc 24/10/2026

Trước khi tin kết quả, mở tab Network trong DevTools, bấm vào yêu cầu đầu tiên và đọc dòng User-Agent trong phần Request Headers. Nếu dòng đó không có chữ Mobile hoặc Android thì bạn đang thử như máy tính. Chế độ thiết bị cũng không tạo ra Referer từ Google, nên nó chỉ thay cho điện thoại, không thay cho bước đi từ kết quả tìm kiếm.

Search Console cho biết Google thấy gì, không cho biết khách thấy gì

Nếu website đã xác minh trong Google Search Console, công cụ Kiểm tra URL cho bạn xem trang như Googlebot tải về. Cách làm: dán địa chỉ trang vào ô kiểm tra ở đầu màn hình, bấm Test live URL, rồi mở View tested page để xem ảnh chụp và HTML đã tải.

Hướng dẫn của Google cũng nêu mục “Crawled as” cho biết Googlebot đã tải trang bằng loại user agent nào, máy tính hay điện thoại. Nếu ảnh chụp ở đây khác hẳn trang bạn thấy, đó là dấu hiệu mã đang trả nội dung khác cho Google.

Giới hạn quan trọng: Googlebot không mang theo Referer từ một kết quả tìm kiếm. Ở máy chủ thử, Googlebot di động cho kết quả sạch ở tổ hợp thứ ba, đúng như bảng ở phần 3. Vì vậy công cụ này bắt được mã nhắm vào bot, nhưng bỏ sót mã chỉ nhắm vào khách đến từ Google. Báo cáo bảo mật của Search Console cũng chỉ nêu những gì Google đã phát hiện; không có cảnh báo chưa có nghĩa là sạch.

Bốn nguyên nhân hợp lệ không phải hack

Không phải mọi chuyển hướng lạ đều do mã độc. Bốn nguyên nhân dưới đây cũng cho ra triệu chứng “điện thoại bị đẩy đi, máy tính thì không”. Loại trừ chúng trước khi báo động.

Nguyên nhân Triệu chứng Cách phân biệt
Cấu hình chuyển bản mobile sai Mọi trang trên điện thoại đều đổ về trang chủ hoặc một địa chỉ cố định Đích nằm trên chính tên miền của bạn; gỡ plugin hoặc quy tắc chuyển hướng thì hết
Script quảng cáo bên thứ ba Bấm vào trang thì mở tab quảng cáo Tắt thẻ quảng cáo hoặc mạng quảng cáo thì hết; đích là trang của mạng đó
Cache theo thiết bị Một số khách thấy trang cũ hoặc bản không hợp thiết bị; trình duyệt nhớ chuyển hướng 301 cũ Xoá cache plugin, thử tab ẩn danh; lỗi hết sau khi xoá
Điện thoại của chính khách Chỉ vài khách bị, cùng một máy hoặc một mạng Wi-Fi công cộng Nhờ khách mở cùng địa chỉ trên máy khác và mạng khác; máy khác bình thường thì lỗi nằm ở máy khách

Tổng hợp từ kinh nghiệm xử lý website; chính sách spam của Google nêu chuyển hướng hợp lệ như đổi địa chỉ site, gộp trang.

Phép thử phân biệt nhanh nhất là “máy khác”. Nhờ chính khách vừa báo lỗi mở cùng địa chỉ trên một điện thoại khác, dùng 4G. Nếu lỗi theo địa chỉ chứ không theo máy, website của bạn có vấn đề. Nếu lỗi theo máy, nguyên nhân nằm ở thiết bị hoặc mạng của họ.

Nếu đích chuyển hướng là một tên miền bạn không biết, và nó không khớp với bất kỳ mạng quảng cáo hay plugin nào bạn cài, hãy coi như site bị xâm nhập và chuyển sang phần dưới.

Mã chuyển hướng thường nằm ở đâu

Khi đã tái hiện được lỗi và loại trừ nguyên nhân hợp lệ, bạn cần tìm đúng chỗ mã ẩn. Sao lưu toàn bộ site trước khi sửa bất cứ thứ gì, để còn đường lùi.

Vị trí Tìm gì
.htaccess ở thư mục gốc Khối RewriteCond kiểm %{HTTP_USER_AGENT} hoặc %{HTTP_REFERER}, đặt trên dòng # BEGIN WordPress hoặc ở cuối tệp
wp-config.php Đoạn PHP lạ ở đầu tệp, hàm giải mã chuỗi, địa chỉ tên miền không thuộc bạn
Tệp JS và PHP của theme, plugin Đoạn mã bị che (obfuscate), gọi tới tên miền lạ; tệp có ngày sửa gần đây mà bạn không chỉnh
wp-content/mu-plugins Plugin tự nạp, không nằm trong danh sách plugin thường; chỉ hiện ở tab Must-Use
Bảng wp_options Giá trị siteurl và home bị đổi; các tuỳ chọn chứa script lạ

Tổng hợp từ hướng dẫn của Patchstack và Fat Lab Web Support về WordPress redirect hack; đọc ngày 22/10/2026.

Các bước dọn chi tiết, gồm kiểm tài khoản quản trị lạ và đổi khoá, đã có trong bài WordPress bị chèn mã độc: cách xử lý, nên bài này không lặp lại. Nếu chuyển hướng kèm trang lạ xuất hiện trên Google, xem tiếp Japanese keyword hack và cách khôi phục thứ hạng sau nhiễm mã độc.

Khi nào nên nhờ người xử lý

Hãy gọi người có kinh nghiệm khi một trong các dấu hiệu sau xuất hiện: tái hiện được chuyển hướng tới tên miền lạ; có tài khoản quản trị bạn không tạo; tệp lõi hoặc .htaccess tự thay đổi sau khi bạn đã sửa lại; hosting khoá tài khoản hoặc Google cảnh báo site.

Số đo từ hệ khách của Net Solutions cho thấy rủi ro không nhỏ: trong 86 site chúng tôi rà soát, 3 site mở cửa REST batch và cả 3 đã bị chiếm. Ca dọn trong bài viết trước có 47 tài khoản quản trị giả và 6 bài mồi bị ghi lùi ngày về 01/01/2020. Dịch vụ chăm sóc website của chúng tôi gồm rà soát định kỳ, sao lưu và xử lý khi có sự cố.

Phản biện công bằng: chúng tôi không thể kết luận một site sạch chỉ bằng phép đo từ xa như curl, và không xử lý được khi không có quyền truy cập máy chủ hoặc bản sao lưu. Nếu site của bạn chỉ vướng một plugin chuyển hướng cấu hình sai, bạn tự gỡ được trong vài phút và không cần ai.

Câu hỏi thường gặp

Vì sao tôi mở website bình thường mà khách thì bị chuyển hướng? Mã chuyển hướng ẩn thường chỉ chạy khi khách dùng điện thoại, đến từ kết quả tìm kiếm, vào lần đầu và chưa đăng nhập. Bạn mở bằng máy tính, đã đăng nhập hoặc gõ thẳng địa chỉ nên rơi ngoài nhóm bị nhắm. Hãy thử lại bằng điện thoại 4G, tab ẩn danh, đi từ kết quả Google.

Chuyển hướng chỉ trên điện thoại có phải bị hack không? Không chắc. Có thể là hack, nhưng cũng có thể do plugin chuyển bản mobile cấu hình sai, script quảng cáo bên thứ ba hoặc cache. Cách phân biệt nhanh: nhờ khách mở cùng địa chỉ trên một điện thoại khác. Nếu đích là tên miền bạn không biết, hãy coi như site bị xâm nhập.

Cách giả lập điện thoại để thử? Có hai cách. Một là dùng curl với User-Agent của Android và Referer của Google, như bảng ở phần 3. Hai là bật chế độ thiết bị trong Chrome DevTools. Cả hai chỉ là xấp xỉ, nên hãy kiểm tra thêm bằng điện thoại thật qua 4G, đi từ Google.

Quét plugin báo sạch mà vẫn bị chuyển hướng thì sao? Công cụ quét có thể không nhận ra mã nhắm vào điều kiện cụ thể hoặc nằm ngoài plugin, như trong .htaccess hay wp_options. Hãy tái hiện lỗi, rồi kiểm tay các vị trí ở phần 7, bắt đầu từ .htaccess và mu-plugins.

Chuyển hướng lạ có làm mất thứ hạng Google không? Google liệt kê chuyển hướng đánh lừa, như đẩy khách điện thoại sang tên miền spam, vào nhóm spam trong chính sách của họ. Chúng tôi không nêu con số mất thứ hạng vì mỗi site khác nhau. Dọn sạch sớm là cách giảm rủi ro.

Nhờ Net Solutions rà soát chuyển hướng lạ

Gửi địa chỉ website và đoạn video khách quay. Chúng tôi kiểm tra các vị trí chứa mã, báo cách xử lý và đường lùi trước khi sửa.

Xem dịch vụ chăm sóc websiteNhắn ZaloHotline 0906.207.001

Cập nhật 27/10/2026 bởi Công ty TNHH Net Solutions.

Gọi ngay Chat Zalo Messenger Facebook Hỗ trợ qua Email