# Уебсайтът пренасочва към чужди страници

> Сайтът Ви пренасочва към чужди страници? Така проверявате слой по слой DNS, CDN, уеб сървъра, PHP кода, базата данни и външните скриптове за причината.

Източник: https://phpsos.de/bg/blog/website-leitet-um/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** Ако сайтът пренасочва към чужди страници, причината е в един от шест слоя: DNS, CDN или прокси, конфигурация на уеб сървъра, PHP код, база данни или вградени скриптове. Тъй като много пренасочвания се задействат само при определени условия, тествайте целенасочено с различни идентификатори и страници на произход. Първо защитете посетителите, запазете следите и след премахването затворете входа за нападателя.

## Когато клиенти попадат на страници с томболи

Съобщението обикновено идва отвън. Клиент пише, че при отваряне на Вашия сайт е попаднал на томбола или на съмнителен магазин. Проверявате на собствения си компютър и всичко изглежда нормално. Това не е противоречие, а умисъл: пренасочванията след хакване са направени така, че операторите да ги забележат възможно най-късно.

За Вашата фирма това е деликатно. Посетителите губят доверие, търсачките и браузърите могат да показват предупреждения, а на целевите страници понякога ви чакат измама или зловреден софтуер. Освен това пренасочването почти никога не е единственото, което атакуващият оставя.

След PHP2Shell, уязвимостите CVE-2026-109618 и CVE-2026-109619 с изпълнение на код без вход в системата, пренасочванията са сред видимите последствия, които операторите трябва да приемат сериозно. Те не са специфичен признак за PHP2Shell, тъй като потвърдени Indicators of Compromise няма. Но показват, че някой е могъл да променя съдържанието на Вашия сайт.

Често пренасочванията не идват сами. Който пренасочва посетители, често създава допълнително и спам страници за търсачките, за да прихване още повече трафик. Ако Google вече показва предупреждение за хакнат сайт, ръководството [Как да премахнете предупреждението на Google](https://phpsos.de/bg/ratgeber/google-warnung-entfernen/) описва пътя към повторната проверка. Чужди страници в индекса на търсачките разглежда статията [SEO спам и чужди страници в индекса на Google](https://phpsos.de/bg/blog/seo-spam-im-google-index/).

## Защо сайтът пренасочва само понякога

Условните пренасочвания оценяват характеристики на заявката. Често това са следните:

- **Произход:** пренасочва се само който идва от резултат от търсене. Директните извиквания показват нормалната страница.
- **Устройство:** засегнати са само мобилни устройства или определени браузъри.
- **Повторение:** пренасочването се задейства веднъж за посетител, след това записва бисквитка и мълчи.
- **Вход в системата:** който е влязъл в CMS, никога не вижда нищо.
- **Време или случайност:** пренасочването се задейства само при част от извикванията.

Затова не тествайте само на работното си място. С четяща заявка виждате как сървърът отговаря на различни извиквания:

```bash
# Нормално извикване: код на състоянието и цел на евентуално пренасочване
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' https://www.ihre-domain.de/

# Извикване като от мобилно устройство, идващо от търсене
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' \
  -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 Mobile/15E148" \
  -e "https://www.google.com/" https://www.ihre-domain.de/
```

Ако чужда цел се появи само при втората заявка, пренасочването е на сървъра. Ако и двете са нормални, то може да се случва в браузъра чрез JavaScript. Тогава помага поглед в изходния код на върнатата страница или в мрежовия изглед на инструментите за разработчици в браузъра, най-добре в частен прозорец.

## Сайтът пренасочва: проверка на шестте слоя

Действайте отвън навътре. Така избягвате с часове да търсите в кода, докато причината е в DNS запис:

| Слой | Типична причина | Проверка |
|---|---|---|
| Домейн и DNS | променен A запис или име сървър | сравнете DNS записите с известното еталонно състояние, проверете достъпа до регистратора |
| CDN или прокси | чуждо правило за пренасочване или за страници | прегледайте правилата в клиентската зона на доставчика |
| Уеб сървър | правила в `.htaccess` или в конфигурацията на сървъра | търсете правила `Rewrite` и `Redirect` с условия |
| PHP код | допълнителен код във входни файлове, шаблони или разширения | сравнете основните файлове с оригинала |
| База данни | променени настройки за адреси, скриптове в съдържание или опции | търсете целенасочено чужди адреси и скриптове |
| Външни скриптове | компрометирано вграждане от трета страна | изброете източниците на вградените скриптове и ги оценете |

Външните слоеве често се прескачат, защото не са на собствения сървър. Точно затова са опасни: който е поел акаунта при регистратора или при доставчика на CDN, не се нуждае от достъп до сървъра. Проверете там освен правилата и кой има достъп и дали е активна двуфакторна автентикация.

За слоя на уеб сървъра подхождат четящи търсения на правила, които реагират на произход или устройство:

```bash
# Правила за пренасочване с условия във всички .htaccess файлове
grep -rn --include='.htaccess' -iE 'Rewrite(Cond|Rule)|Redirect' /var/www/ihre-website

# Пренасочвания в конфигурацията на сървъра (Apache и Nginx)
grep -rn -iE 'Rewrite|Redirect|return 30[12]' /etc/apache2/ /etc/nginx/ 2>/dev/null
```

За PHP слоя подходът е описан в [Сравняване на основните файлове на CMS с оригинала](https://phpsos.de/bg/blog/cms-kerndateien-vergleichen/). За базата данни си струва статията [Проверка на базата данни за внедрен код](https://phpsos.de/bg/blog/datenbank-auf-schadcode-pruefen/).

## Когато причината е извън сървъра

Не всяко пренасочване означава компрометиран сървър. Вградени скриптове на трети страни, например за чат, статистика или реклама, се изпълняват директно в браузъра на посетителите. Ако такъв доставчик бъде компрометиран или изтече домейн, от който Вашата страница още зарежда скрипт, чрез него може да възникне пренасочване, без на Вашия сървър да е променен файл.

Content Security Policy ограничава от кои източници браузърът може да зарежда скриптове и прави такива случаи видими. Насоки има в [Хедъри за сигурност на уебсайтове](https://phpsos.de/bg/ratgeber/sicherheits-header/). Съвсем рядко причината е при самия посетител: рекламен или зловреден софтуер на неговия компютър пренасочва тогава и на други уебсайтове.

## Правилният ред след откритието

1. **Защитете посетителите:** поставете сайта в режим на поддръжка или блокирайте засегнатите области.
2. **Запазете следите:** копирайте съмнителни правила, файлове и съдържание на базата данни с времеви печат, преди да ги премахнете.
3. **Премахнете:** отстранете пренасочването и заменете основните файлове от чист източник.
4. **Затворете входа:** доведете PHP до коригирана версия, актуализирайте CMS и разширенията, рестартирайте всички worker процеси, подновете достъпите.
5. **Тествайте отново:** проверете пак с всички варианти от втория раздел и наблюдавайте Search Console.

> **Важно:**
> Премахнатото правило за пренасочване не е доказателство за чист сайт. Ако правилото се върне след дни, някъде още има задна врата, която го пише наново.

## Как помага PHP SOS конкретно?

- Възпроизвеждаме пренасочването с различни идентификатори и страници на произход и ограничаваме слоя.
- Запазваме следите и премахваме пренасочвания, зловреден код и задни врати във файловете, конфигурацията и базата данни.
- При остър проблем нашата [спешна помощ при хакнати уебсайтове](https://phpsos.de/bg/leistungen/website-gehackt-notfallhilfe/) поема ограничаването, докато инцидентът бъде приключен и документиран.
- Проверяваме вградените скриптове на трети страни и препоръчваме подходяща Content Security Policy.


## Често задавани въпроси

**Защо не виждам пренасочването сам?**  
Много пренасочвания се задействат само при определени условия: за посетители от търсачката на Google, само на мобилни устройства, само при първото посещение или не за влезли администратори. Затова тествайте с различни устройства, без вход в системата и през връзка от резултат от търсене.

**Може ли пренасочване да възникне и без хакване?**  
Да. Изтекла добавка, компрометиран външен скрипт, грешни DNS записи или зловреден софтуер на компютъра на посетителя могат да дадат подобни ефекти. Ако причината е на собствения компютър, пренасочването обикновено се появява и на други уебсайтове.

**Къде атакуващите най-често крият пренасочванията?**  
Типични са правила в .htaccess или в конфигурацията на сървъра, допълнителен код във входни файлове на приложението, променени настройки за адреси в базата данни и внедрени JavaScript фрагменти в съдържание или шаблони.

**Какво да направя веднага, ако сайтът ми пренасочва?**  
Защитете посетителите, например чрез режим на поддръжка, и запазете следите, преди да изтриете каквото и да било. След това търсете причината слой по слой и затворете входа за нападателя. Премахнато правило без затворена уязвимост обикновено се връща.

## Източници

- [Помощ за Google Search Console](https://support.google.com/webmasters/)
- [Документация на Apache HTTP Server](https://httpd.apache.org/docs/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)