Имаме инструкции и информация за всичко.

За да предложим на клиентите си изключителна производителност и надеждност, които отговарят и на най-високите изисквания, използваме само най-мощните и надеждни сървърни компоненти за хардуерната конфигурация на нашите сървъри.

Всеки наш хостинг сървър разполага с два многоядрени (до 18 ядра) Xeon процесора, до 256 GB DDR4 RAM, както и RAID 6 масиви от SSD устройства с по няколко терабайта пространство.

Използваме RAID 6, тъй като предлага най-добрата комбинация от производителност и надеждност. Производителността е същата като на RAID 5, а записаните данни са защитени, дори в случай че две от SSD устройствата в масива откажат едновременно.

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

Гарантираната непрекъсната интернет връзка чрез многобройни оптични линии към различни доставчици и непрекъснатото електрическо захранване от мрежата и резервните генератори за електрическа енергия също са ключови фактори за най-високото ниво на свързаност и надеждност на нашите сървъри.

Всички наши сървъри използват модифицирана 64-битова версия на Debian GNU/Linux с Apache уеб сървър.

На нашата хостинг платформа се поддържат технологиите PHP, Python, Perl, Ruby, Tcl и MySQL. MySQL поддържа MyISAM и InnoDB подсистемите. Можете да откриете детайлна информация за поддържаните версии на тези технологии на нашите сървъри в раздел Информация за сървъра на Контролния панел.

Хостинг акаунти с наличен раздел Уеб приложения в Контролния панел могат да използват и други софтуерни приложения, работещи в собствена среда за изпълнение. Такива приложения могат да бъдат базирани на Node.js, Django, Flask, Ruby on Rails и други. Свържете се с Вашия хостинг доставчик за повече информация, ако не виждате раздел Уеб приложения във Вашия Контролен панел.

Нашите хостинг сървъри използват модифицирана 64-битова Debian GNU/Linux операционна система с Apache уеб сървър и поддръжка за MySQL (подсистеми MyISAM и InnoDB), PHP, Pyhon, Perl, Ruby и Tcl. Пълен списък с версиите на инсталирания софтуер за Вашия акаунт е наличен в раздел Информация за сървъра на хостинг Контролния панел.

Ако виждате раздел Уеб приложения във Вашия хостинг Контролен панел, можете да инсталирате софтуерни приложения работещи в собствена среда за изпълнение (като например Django, Node.js, Flask, Ghost, Ruby on Rails, MongoDB и PostgreSQL). Свържете с Вашия хостинг доставчик, ако не виждате раздела Уеб приложения във Вашия хостинг Контролен панел, но желаете да се възползвате от поддръжката на уеб приложения на сървърите.

Mod_deflate е модул на уеб сървъра Apache. Използва се за компресиране на трансферираното съдържание от сървъра към браузъра на потребителя с цел намаляване на генерирания от сайта трафик. Компресията се извършва автоматично без да е нужна интеракция от страна на потребителя – единственото условие е браузърът му да поддържа gzip компресия. Повечето съвременни браузъри като Internet Explorer, Mozilla Firefox, Chrome, Safari и др. имат такава вградена поддръжка и не е нужна инсталация на допълнителен софтуер.

• Как протича gzip компресията?

Браузърът на клиента изпраща автоматично информация дали поддържа gzip компресия, когато направи запитване към сървъра за определен файл – например http://www.example_domain.com/index.html. Ако сте конфигурирали Apache да използва mod_deflate, то съдържанието на index.html ще бъде компресирано в gzip формат и изпратено на браузъра. Той от своя страна ще разкомпресира gzip файла и ще го покаже в прозореца на потребителя като обикновен html файл без потребителят да е разбрал за тези операции.

• Как да използвам mod_deflate?

За да използвате mod_deflate е нужно да създадете файл с име .htaccess (обърнете внимание на точката пред името на файла) със следното съдържание:

<IfModule deflate_module>
AddOutputFilterByType DEFLATE text/css text/csv text/html text/plain text/richtext text/sgml text/tab-separated-values application/javascript application/x-javascript httpd/unix-directory
AddOutputFilter DEFLATE html htm shtml php php4 pl rb py cgi css js txt
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
</IfModule>
Съхранете този файл в директорията, в която искате да използвате gzip компресия. Имайте предвид, че .htaccess файловете имат рекурсивно действие – това означава, че настройките са активни не само за директорията, където се намира .htaccess файла, но и за нейните поддиректории.
Чрез горния .htaccess файл mod_deflate компресията ще бъде активна за всички HTML, SSI,PHP, Perl, Ruby, Python, CGI, Cascading Style Sheets, JavaScript и текстови файлове.

Mod_brotli е модул на уеб сървъра Apache. Използва се за компресиране на трансферираното съдържание от сървъра към браузъра на потребителя с цел намаляване на генерирания от сайта трафик. Компресията се извършва автоматично без да е нужна интеракция от страна на потребителя – единственото условие е браузърът му да поддържа brotli компресия. Повечето съвременни браузъри като Internet Explorer, Mozilla Firefox, Chrome, Safari и др. имат такава вградена поддръжка и не е нужна инсталация на допълнителен софтуер. 

• Как протича компресията? 

Браузърът на клиента изпраща автоматично информация дали поддържа brotli компресия, когато направи запитване към сървъра за определен файл – например http://www.example_domain.com/index.html. Ако сте конфигурирали Apache да използва mod_brotli, то съдържанието на index.html ще бъде компресирано и изпратено на браузъра. Той от своя страна ще разкомпресира файла и ще го покаже в прозореца на потребителя като обикновен html файл без потребителят да е разбрал за тези операции. 

• Как да използвам mod_brotli? 

За да използвате mod_brotli е нужно да създадете файл с име .htaccess (обърнете внимание на точката пред името на файла) със следното съдържание: 

<IfModule brotli_module>
AddOutputFilterByType BROTLI_COMPRESS text/css text/csv text/html text/plain text/richtext text/sgml text/tab-separated-values application/javascript application/x-javascript httpd/unix-directory
</IfModule>
Съхранете този файл в директорията, в която искате да използвате brotli компресия. Имайте предвид, че .htaccess файловете имат рекурсивно действие – това означава, че настройките са активни не само за директорията, където се намира .htaccess файла, но и за нейните поддиректории. 

Чрез горния .htaccess код, mod_brotli компресията ще бъде активна за всички HTML, SSI, PHP, Perl, Ruby, Python, CGI, Cascading Style Sheets, JavaScript и текстови файлове.

Mod_speling е модул на уеб сървъра Apache. Файловата система на Linux е чувствителна към главни и малки букви. Mod_speling цели да разреши проблеми с имената на файлове, в които има комбинация от главни и малки букви. Можете да срещнете такива проблеми, ако трансферирате при нас сайт, който е създаден за сървър базиран на Windows, или ако сте разработили сайта си на програма на Windows.  

• Как да използвам mod_speling?

За да използвате mod_speling е нужно да създадете файл с име .htaccess (обърнете внимание на точката пред името на файла) със следното съдържание: 

<IfModule mod_speling.c>
CheckSpelling on
CheckCaseOnly on
</IfModule>

Съхранете този файл в директорията, в която искате да използвате mod_speling. Имайте предвид, че .htaccess файловете имат рекурсивно действие – това означава, че настройките са активни не само за директорията, където се намира .htaccess файла, но и за нейните поддиректории. 

Папката icons е предварително дефинирана от уеб сървъра за целите на хостинг услугите. Ето защо, ако се опитате да я създадете в някой от вашите поддомейни (включително www) чрез Контролния панел или чрез FTP клиент, ще можете да виждате нейното съдържание единствено чрез тях. То няма да бъде достъпно за браузъра ви, тъй като уеб сървърът отваря своята предварително дефинирана от него папка icons, пренебрегвайки вашата.

Изброили сме някои от най-често срещаните причини, поради които можете да получите “500 Server Error” грешка:

• Неправилни права на вашите файлове/директории

Това е най-често срещаната причина за 500 Server Error. Моля, проверете дали вашите файлове са с права за достъп 666 или 777. Също така проверете дали директорията, в която се намират скриптовете, не е с такива права.
На нашите сървъри не е необходимо да задавате права за писане за всички (world-writable). Достатъчно е да настроите правата на 644 или 664 за файлове и 755 или 775 за директории.

Когато желаете определен скрипт да може бъде изпълняван от потребителите на вашия сайт, то задължително неговите права за достъп трябва да започват или с 07 (т.е. -rwx) или с 05 (т.е. -r-x), пример: 0775 (т.е. -rwxrwxr-x), 0755 (т.е. -rwxr-xr-x), 0750 (т.е. -rwxr-x—), 0700 (т.е. -rwx——) и т.н. Това ще позволи той да бъде изпълняван от вашия потребител, респективно уеб сървъра Apache, а липсата на тези права ще доведе до 500 Server Error. За повече информация относно правата за достъп и какво означават те, погледнете раздела Права на файлове и директории (CHMOD) от нашата документация.

• Невалидни или грешни команди в .htaccess

Ако изведнъж сте започнали да получавате “500 Server Error” грешки, може би е заради това, че сте променили нещо по ваш .htaccess файл.
Грешката “500 Server Error” се появява често, когато се опитвате да използвате php_flag инструкции. Тъй като PHP работи на нашите сървъри като CGI или FPM, а не като Apache модул, не е възможно да използвате php_flag инструкции за промяна на PHP настройките. За тази цел е нужно да създадете php.ini файл – за повече информация ви съветваме да разгледате статията Промяна на php.ini настройките за вашия акаунт.

• Използване на Windows EOL (end-of-lines) символи

Този проблем може да се появи, когато сте използвали текстов редактор като Notepad или Wordpad. Добавяйки нов ред, текстовите редактори са вмъкнали EOL символи на Microsoft Windows, които се различават от UNIX символите на операционната система Linux, която използваме на нашите сървъри.
За да отстраните този проблем, отворете файла чрез секцията Файлове във вашия Контролен панел и без да го модифицирате, натиснете бутона “Запази и излез”. Така Windows EOL символите ще бъдат подменени с UNIX EOL  и вашият скрипт ще може да бъде изпълнен без 500 Server Error. Съветваме ви вместо Notepad или Wordpad да използвате някой от следните безплатни текстови редактори, които позволяват да укажете кои EOL символи да бъдат използвани:
– PSPad (www.pspad.com)
– Notepad++ (http://notepad-plus.sourceforge.net/bg/site.htm)

• Неправилен системен път към Perl, Ruby или Python интерпретатора

Ако използвате Perl, Ruby или Python скрипт, то проверете какъв системен път използвате в началото му. За да видите къде се намират интерпретаторите на изброените езици на файловата система на сървъра, използвайте секцията “Информация за сървъра” във вашия Контролен панел – за повече информация погледнете статията Информация за сървъра.

• Обща информация за FastCGI и PHP-FPM
• Какво пропускате, ако използвате FastCGI вместо FPM?
• Прекратяване на поддръжката за FastCGI
• Преминаване от FastCGI на FPM
  
  

Обща информация за FastCGI и PHP-FPM

FastCGI

FastCGI за PHP е значително подобрение на традиционната CGI технология за изпълнение на PHP скриптове. FastCGI се поддържа на нашите VPS решения от 2016 г. За разлика от традиционната CGI технология за изпълнение на PHP скриптове, FastCGI позволява един процес да обработва множество заявки преди да бъде прекратен. Намаляването на излишните ресурси за стартиране на нов PHP процес за всяка нова заявка значително подобрява времето за изпълнение на отделните заявки и намаля потреблението на ресурси. Благодарение на подобрената си технология, FastCGI намалява времето за зареждане на сайтовете и позволява едновременното изпълнение на по-голям брой заявки. FastCGI поддържа и OPcache – система за кеширане, която пази предварително компилиран байт код в сървърната памет. Това допълнително забързва изпълнението на PHP скриптове и увеличава производителността.

PHP-FPM

FPM (FastCGI Process Manager) е по-нова версия на FastCGI технологията със значителни подобрения (особено за натоварени сайтове). PHP-FPM е една от най-ефективните и стабилни технологии за изпълнение на PHP, като се поддържа изцяло на всички наши сървъри за споделен хостинг и VPS решения. Използвайки FastCGI протокола, FPM има всички предимства на FastCGI технологията за изпълнение на PHP скриптове, но може да поддържа работещите FastCGI процеси за изпълнение на PHP заявки активни през цялото време. Това води до още по-бързо изпълнение на PHP скриптове. PHP-FPM създава допълнителни FastCGI процеси при необходимост, за да изпълни всички заявки максимално бързо и навреме. PHP-FPM е настроен да работи с OPcache по подразбиране и използва OPcache ресурсите много по-ефективно от FastCGI, тъй като ги споделя между всички PHP-FPM процеси.

Какво пропускате, ако използвате FastCGI вместо FPM?

Ето някои от предимствата на FPM спрямо FastCGI:

• FPM обработва заявки по-бързо (над 30%) от FastCGI, позволявайки едновременното изпълнение на над 30% повече заявки в сравнение с FastCGI.
• FPM подобрява изживяването на посетителите на сайтовете и спомага по-доброто класиране в търсачки благодарение на повече от 5 пъти по-бързото време за зареждане на първия байт (TTFB – Time To First Byte). Това подобрение се дължи на поддържането на работещи FastCGI процеси от FPM, докато FastCGI трябва да създава нов работещ процес, ако няма активен и свободен такъв.
• FPM се поддържа на всички наши сървъри, а FastCGI може да се активира само на определени VPS решения.
• FastCGI може да се активира само ръчно, докато FPM може да се активира с един клик на мишката в раздел “PHP настройки” на Контролния панел.
• OPcache е включен по подразбиране за FPM, но за FastCGI трябва да се включи ръчно.
• FPM има по-добра поддръжка и се изпробва по-обстойно от PHP проекта.
  
  

Прекратяване на поддръжката за FastCGI

Тъй като имплементацията на FPM технологията на нашите сървъри няма никакви недостатъци спрямо нейния FastCGI еквивалент, постепенно ще спрем поддръжката за FastCGI технологията. Поради тази причина Ви съветваме да преминете към FPM възможно най-скоро.

Преминаване от FastCGI на FPM

Преминаването от CGI/FastCGI към FPM на нашите сървъри е изключително лесно. Всичко, което е необходимо да направите, е да промените PHP технологията за Вашия домейн/поддомейн от “CGI” на “FPM с OPcache” през раздел “PHP настройки” на Контролния панел. Можете да откриете информация как да промените PHP технологията в статията Поддържани версии на PHP.

Въпреки че този процес е незадължителен, Ви съветваме да извършите в обратен ред стъпките за активиране на FastCGI (описани в статията ни Използване на FastCGI + OPcache), премахвайки:

• блока с код <IfModule mod_fcgid.c> от .htaccess файла в директорията на Вашия сайт;
  
• .ht-fcgi-php-wrapper файла от директорията на Вашия сайт;
  
• блока с код [opcache] от основния php.ini файл за Вашия сайт.
  

Важно:FPM технологията за изпълнение на PHP скриптове работи безпроблемно с множество уеб приложения, но Ви съветваме старателно да проверите Вашия сайт за проблеми след преминаване към FPM, тъй като определено уеб приложение или скрипт може да не е съвместим с FPM. В такъв случай трябва да промените PHP технологията за Вашия сайт на CGI.

Ако срещнете някакви проблеми или имате нужда от помощ при преминаването от FastCGI към FPM, можете да се свържете с отдела ни за техническа поддръжка.

• 1. Какво е .htaccess?
  
  Файлът .htaccess служи за конфигурация на уеб сървъра Apache и чрез него могат да бъдат променяни редица функции на сървъра. Зададените настройки важат за директорията, в която се намира .htaccess файла, и нейните поддиректории. Файлът задължително започва със знака точка и може да бъде създаден лесно в секция Файлове на Контролния панел. За да свалите локално конфигурационния файл, използвайте FTP програма и след това можете да го редактирате с текстов редактор. Имайте предвид, че повечето FTP програми не показват по подразбиране файлове с имена започващи с точка. За да видите .htaccess файловете, е нужно да активирате функцията “Show Hidden Files” в настройките на вашата FTP програма.

  
  2. Полезни примери

  2.1Забрана за достъп до определени файлове
  2.2Добавяне на Content-Type хедър към вашите страници
  2.3Използване на определена времева зона
  2.4Принудително сваляне на файл
  2.5Забрана за достъп до съдържанието на вашите директории
  2.6Създаване на собствени Еrror страници
  2.7Предотвратяване на hot linking
  2.8Блокиране на достъпа от определен IP адрес или мрежа
  2.9Уведомяване на посетителите за текуща реконструкция
  2.10Блокиране на достъпа до сайта според часа
  2.11Принудително използване на www.your_domain.com
  
  
  2.1 Забрана за достъп до определени файлове^
  
  Със следния код можете да забраните достъпа до файлове с определени разширения – в този пример става дума за всички файлове, които имат разширение .txt. В случая посетителите ще виждат страница с грешка “403 Forbidden” вместо съдържанието на .txt файла.
  <Files ~ “\.txt$”>
  Order Allow,Deny
  Deny from All
  </Files>А ако искате да забраните достъпа например до всички .txt .doc .rtf .log .fla .psd файлове, използвайте следния код:
  <FilesMatch “\.(txt|doc|rtf|log|fla|psd)$”>
  Order Allow,Deny
  Deny from all
  </FilesMatch>
  2.2 Добавяне на Content-Type хедър към вашите страници^
  
  За да добавите Content-Type хедър, така че сървърът да съобщава за кодирането на всяка ваша страница на браузъра, използвайте директивата AddDefaultCharset. Ето два примера:
  AddDefaultCharset UTF-8
  AddDefaultCharset ISO-8859-1
  2.3 Използване на определена времева зона^
  
  Чрез следния ред можете да принудите PHP скриптовете ви да използват вашата времева зона вместо тази на сървъра:

  SetEnv TZ Europe/London

  Пълен списък с поддържаните часови зони можете да намерите на следния адрес: http://php.net/manual/bg/timezones.php
  
  
  2.4Принудително сваляне на файл^
  
  Този пример задава условието файлове с изброените разширения да не се отварят в браузъра или с допълнителни програми като QuickTime, Adobe Reader и др., а да се появява прозорец със запитване къде да бъдат съхранени:
  <FilesMatch “\.(mov|mp3|jpg|pdf)$”>
  ForceType application/octet-stream
  Header set Content-Disposition attachment
  </FilesMatch>
  2.5 Забрана за достъп до съдържанието на вашите директории^
  
  Създайте .htaccess файл с реда по-долу, ако например нямате index страница и искате да забраните показването на всички файлове в директорията. Така никой освен вас няма да знае какво е съдържанието на дадената директория.
  Options -Indexes
  Същият ефект би могъл да бъде постигнат и чрез създаването на празен index.html файл в дадената директория.
  
  Ако все пак искате потребителите да виждат съдържанието на директориите ви освен определени типове файлове, които да останат скрити, използвайте код от следния вид:
  IndexIgnore *.php *.htmlПо този начин всички ваши PHP и HTML файлове няма да бъдат листвани заедно с останалите.
  
  
  2.6 Създаване на собствени Еrror страници^
  
  Ако не ви харесват стандартните страници за грешки, посредством .htaccess можете да създадете собствени. В следващия пример дефинираните страници за грешки са в директория “errors”, намираща се в главната ви директория www.
  ErrorDocument 403 /errors/403.html
  ErrorDocument 404 /errors/404.html
  Общият вид на всеки ред е: ErrorDocument <номер на http статус код> <път/до/файл>
  
  Линкът до вашия документ за грешка може да сочи също така страница за грешка, намираща се на друг сайт:
  ErrorDocument 404 http://another_domain.com/404.phpВместо линк или файл можете да зададете на .htaccess да показва текстово съобщение като използвате:
  ErrorDocument 404 “This page was not found on this server”или HTML:
  ErrorDocument 404 “<html><title>Not Found</title><body>This page was not found on this server.</body></html>”Важно: Забележете кавичките, които се поставят преди съобщението за грешка и които трябва да липсват в края на съобщението.
  
  Baжно: Ако сами искате да дефинирате страницата за грешка 404, е нужно да изтриете missing.html документа от вашата главна директория www. Internet Explorer не зарежда страници за грешки, които са по-малки от 512 байта и нужно вашето съобщение за грешка да е по-голямо от 512 байта.
  
  
  2.7 Предотвратяване на hot linking^
  
  Hot linking представлява директното използване на някои от файловете (най-често картинки), намиращи се на вашия сайт, от страна на друг сайт, най-често без ваше разрешение, като тези файлове стават част от съдържанието на чуждия сайт. Това причинява изразходен трафик от другите сайтове за ваша сметка или казано по друг начин – кражба на трафик.
  
  • Блокиране само на определени домейни
  
  За да забраните hot linking на картинки от определени сайтове (в примера от not_your_domain.net, www.not_your_domain.net и not_your_domain.com, www.not_your_domain.com), като оставите на всички останали сайтове правото да използват hot linking, използвайте следния код, при който вместо картинката ще се показва грешка “403 Forbidden”:
  RewriteEngine On
  RewriteCond %{HTTP_REFERER} ^http://(www\.)?not_your_domain\.net/ [NC,OR]
  RewriteCond %{HTTP_REFERER} ^http://(www\.)?not_your_domain\.com/ [NC]
  RewriteRule \.(jpeg|JPEG|jpe|JPE|jpg|JPG|gif|GIF|png|PNG|tif|TIF|tiff|TIFF)$ – [F]
  • Блокиране на всички домейни освен определени
  
  В следващия пример се предотвратява hot linking от всички сайтове с изключение на вашия домейн, където се намират картинките:
  RewriteEngine On
  RewriteCond %{HTTP_REFERER} !^http://(www\.)?your_domain\.com/ [NC]
  RewriteCond %{HTTP_REFERER} !^$
  RewriteRule \.(jpeg|JPEG|jpe|JPE|jpg|JPG|gif|GIF|png|PNG|tif|TIF|tiff|TIFF)$ – [F]Моля, имайте предвид, че ако имате паркирани домейни, трябва да добавите всеки един от тях в този код, за да важи това правило и за тях. Пример за един главен домейн и три паркирани:
  RewriteEngine On
  RewriteCond %{HTTP_REFERER} !^http://(www\.)?your_domain\.com/ [NC]
  RewriteCond %{HTTP_REFERER} !^http://(www\.)?your_parked_domain1\.com/ [NC]
  RewriteCond %{HTTP_REFERER} !^http://(www\.)?your_parked_domain2\.com/ [NC]
  RewriteCond %{HTTP_REFERER} !^http://(www\.)?your_parked_domain3\.com/ [NC]
  RewriteCond %{HTTP_REFERER} !^$
  RewriteRule \.(jpeg|JPEG|jpe|JPE|jpg|JPG|gif|GIF|png|PNG|tif|TIF|tiff|TIFF)$ – [F]
  • Заместване на картинки
  
  Този метод все още ще води до кражба на трафик, но ще защити вашите картинки. Моля, обърнете внимание, че някои програми (например phpBB) при това условие изглежда разпознават статус 302 като грешка и започват да правят многократни опити да презаредят, докато потребителят не зареди друга страница.
  
  Със следния код отдалеченият сървър ще зареди изображението unknown.jpg от директорията images в главния ви поддомейн www вместо поисканите картинки:
  RewriteEngine On
  RewriteCond %{HTTP_REFERER} !^http://(www\.)?your_domain\.com/ [NC]
  RewriteCond %{HTTP_REFERER} !^http://(www\.)?your_parked_domain1\.com/ [NC]
  RewriteCond %{HTTP_REFERER} !^$
  RewriteRule \.(jpeg|JPEG|jpe|JPE|jpg|JPG|gif|GIF|png|PNG|tif|TIF|tiff|TIFF)$ images/unknown.jpg [L]
  2.8 Блокиране на достъпа от определен IP адрес или мрежа^
  
  • Блокиране на достъпа от определени IP адреси
  
  Ако искате да забраните достъпа по HTTP от определени IP адреси (в примера 64.14.68.138 и 64.14.68.139), създайте .htaccess файл със следното съдържание:
  order allow,deny
  deny from  64.14.68.138
  deny from 64.14.68.139
  allow from all• Блокиране на достъпа от определен определена мрежа
  
  Можете да забраните и цяла мрежа. За да блокирате например всички IP адреси, започващи с 64.14.68. (т.е. мрежата 64.14.68), използвайте следния код:
  order allow,deny
  deny from 64.14.68.
  allow from all• Блокиране на достъпа от всички IP адреси и мрежи
  
  Ако желаете да забраните достъпа на всички, използвайте следния ред във вашия .htaccess файл:
  deny from allОсвен IP адреси, в .htaccess файла можете да използвате и имена на домейни:
  deny from example.comА за да блокирате достъпа от всички поддомейни на example.com, използвайте:
  deny from .example.com
  2.9 Уведомяване на посетителите за текуща реконструкция^
  
  Ако сте решили, че ще правите реконструкция на вашия сайт и желаете вместо да блокирате достъпа до нея, да позволите на посетителите да разберат, че сайта ви подлежи на реконструкция, е нужно да изготвите един файл maintenance.html в главната ви директория www. Неговотo съдържание ще се показва на посетителите, докато сайтът ви не е достъпен. След това добавете следните редове в .htaccess файла, който се намира в главната директория www:

  RewriteEngine On
  RewriteCond %{REQUEST_URI} !/maintenance.html$
  RewriteRule .* /maintenance.html [R=307,L]
  2.10 Блокиране на достъпа до сайта според часа^
  
  Ако желаете посетителите ви да имат достъп до вашия сайт само в работното ви време (7:00 – 19:00 ч.), използвайте следния код:
  RewriteEngine On
  RewriteCond %{TIME_HOUR}%{TIME_MIN} >1900 [OR]
  RewriteCond %{TIME_HOUR}%{TIME_MIN} <0700
  RewriteRule ^.*$ – [F,L]Ако желаете да забраните достъп до сайта ви в обедната си почивка, използвайте следния код, който ще забрани достъпа от 12:00 до 12:59 през деня:
  RewriteEngine On
  RewriteCond %{TIME_HOUR} ^12$
  RewriteRule ^.*$ – [F,L]
  2.11 Принудително използване на www.your_domain.com^
  
  Ако желаете посетителите на вашия сайт винаги да бъдат препращани към www.your_domain.com, когато направят заявка до your_domain.com или до някой от паркираните ви домейни, използвайте следния код:
  RewriteEngine On
  RewriteCond %{REQUEST_URI} !^/robots\.txt$
  RewriteCond %{HTTP_HOST} !^www\.your_domain\.com$ [NC]
  RewriteRule ^(.*)$ http://www.your_domain.com/$1 [R=301,L]

• Какво е .ftpaccess?

  Файлът .ftpaccess служи за конфигурация на FTP сървъра ProFTPD и чрез него могат да бъдат променяни редица функции на сървъра. Файлът задължително започва със знака точка и може да бъде създаден лесно в раздел “Файлове” на Контролния панел.

  За да свалите локално конфигурационния файл, използвайте FTP програма и след това можете да го редактирате с текстов редактор. Имайте предвид, че повечето FTP програми не показват по подразбиране скрити файлове и такива, които започват с точка. За да видите .ftpaccess файловете, е нужно да активирате функцията “Show Hidden Files” в настройките.

  За какво служи директивата Limit?

  Директивата “Limit” позволява ограничиването и позволяването на достъпа до определени FTP команди в дадена директория. Ако искате да контролирате достъпа в няколко директории/поддиректории, трябва да добавите .ftpaccess във всяка от тях.

  По-долу можете да откриете списък с групите команди, най-използваните FTP команди и кратко описание за тях:

  • ALL включва READ, WRITE и DIRS командните групи (всички FTP команди). Тази командна група има най-малък приоритет от всички останали – тя няма да презапише “Limit” директива, която е зададена от друга командна група като например “DIRS“.
  • READ включва всички FTP команди, които са свързани с четенето на файлове (не се включва показването на директории):
    • RETR (RETRieve) позволява изтеглянето на файлове от сървъра.
    • SITE CHMOD (CHange MODe) позволява промяната на правата за достъп (permissions) до файлове и директории.
    • SIZE позволява виждането информация за големината на файлове.
    • STAT (STATus) позволява показването на информация за FTP сървъра и връзката.
  • WRITE включва FTP команди за писане, създаване и изтриване на файлове и директории:
    • APPE (APPEnd) позволява добавянето на съдържание от един файл в друг.
    • DELE (DELEte) позволява изтриването на файлове и директории.
    • MKD/XMKD (MaKe Directory) позволява създаването на нови директории.
    • RMD/XRMD (ReMove Directory) позволява изтриването на директории.
    • RNTO (ReName TO) позволява преименуването на файлове/директории. Тази команда се използва в комбинация с FTP командата RNFR.
    • STOR (STORe) позволява качването на файлове на сървъра.
  • DIRS включва следните FTP команди, свързани с показването на инфомация за директории:
    • CDUP/XCUP (Change Directory UP) позволява навигирането до горната директория на текущата.
    • CWD/XCWD (Change Working Directory) позволява промяната на текущата директория.
    • LIST/NLST (LIST/Name LiST) позволява показването на списък с файловете в директория.
    • MDTM (MoDification TiMe) позволява показването на информация за датата на промяна на файлове.
    • PWD/XPWD (Print Working Directory) позволява показването на текущата директория.
    • RNFR (ReName FRom) позволява преименуването на файлове/директории. Тази команда се използва в комбинация с FTP командата RNTO.

  Повече информация относно “Limit” директивата са налични в официалната документация на ProFTP.
  
  

  Сигурност

  Съветваме Ви да използвате винаги следния код в началото на Вашите .ftpaccess файлове:
  HideFiles (\.ftpaccess|\.htaccess|\.htpasswd)$ user !alloweduser
  <Limit ALL>
  IgnoreHidden on
  </Limit>По този начин Вашите .ftpaccess, .htaccess и .htpasswd файлове няма да могат да се виждат и да бъдат променяни през FTP освен от alloweduser (заместете alloweduser с Вашето FTP потребителско име, чрез което желаете да виждате и променяте по-горе изброените файлове).
  След като създадете .ftpaccess файл, Ви съветваме да промените правата му за достъп от секцията Файлове в Контролния панел до 0600 за максимална сигурност, а и за да не бъде достъпен по HTTP.

  Полезни примери

  По-долу можете да откриете няколко примера за употреба на .ftpaccess файл:

  1. Блокиране на FTP достъп
     • от определени IP адреси или мрежи
     • отвсякъде (всички IP адреси и мрежи)
     • отвсякъде освен определени IP адреси и мрежи
  2. Забраняване триенето на файлове и директории
  3. Забраняване качването на файлове и създаването на директории
     • за всички без определени FTP потребители
     • смесена кофигурация
  4. Позволяване само на качване на файлове
  5. Забраняване на достъп до дадена директория за определени FTP потребители
  6. Разрешаване на достъп само за определени FTP потребители
  7. Позволяване на изтриването на файлове само от определени IP адреси или мрежи
  8. Ограничаване промяната права за достъп за определени FTP потребители
     
     

  1. Блокиране на FTP достъп

  • от определени IP адреси или мрежи
    
    За да блокирате FTP достъпа до директория от определени IP адреси (напр. 1.2.3.4) или мрежи (напр. всички IP адреси, започващи с 5.6.7), добавете следния блок с код към .ftpaccess файл в тази директория:
    
    <Limit ALL>
    Order allow,deny
    Deny from 1.2.3.4
    Deny from 5.6.7.
    </Limit>

    Важно: Тъй като .ftpaccess файловете не работят рекурсивно, трябва да добавите отделен .ftpaccess файл във всички директории, където искате да приложите зададената настройка.
    
    

  • отвсякъде (всички IP адреси и мрежи)
    
    Можете напълно да ограничите FTP достъпа до директория, добавяйки следния блок с код в .ftpaccess файл в директорията:
    
    <Limit ALL>
    Order allow,deny
    Deny from all
    </Limit>
    

    Важно: Тъй като .ftpaccess файловете не работят рекурсивно, трябва да добавите отделен .ftpaccess файл във всички директории, където искате да приложите зададената настройка.
    
    

  • отвсякъде освен определени IP адреси и мрежи
    
    За да ограничите FTP достъпа до директория за всички освен определени IP адреси (напр. 1.2.3.4) или мрежи (напр. всички IP адреси, започващи с 5.6.7), използвайте следния код в .ftpaccess файл в тази директория:
    
    <Limit ALL>
    Order allow,deny
    Allow from 1.2.3.4
    Allow from 5.6.7.
    Deny from all
    </Limit>
    Важно: Тъй като .ftpaccess файловете не работят рекурсивно, трябва да добавите отделен .ftpaccess файл във всички директории, където искате да приложите зададената настройка.

  2. Забраняване триенето на файлове и директории

  Ако желаете да забраните триенето на файлове и директории за всички потребители освен за един (напр. allowed_user), използвайте следния код в .ftpaccess файла на директорията:

  <Limit DELE RMD XRMD>
  AllowUser allowed_user
  DenyAll
  </Limit>

  Важно: Тъй като .ftpaccess файловете не работят рекурсивно, трябва да добавите отделен .ftpaccess файл във всички директории, където искате да приложите зададената настройка.

  3. Забраняване качването на файлове и създаването на директории

  • за всички без определени FTP потребители
    
    Ако желаете да позволите на всички FTP потребители да виждат съдържанието на директория, но да забраните качването на файлове и създаването на директории в нея за всички с изключение на два FTP потребителя (напр. allowed_user_1 и allowed_user_2), добавете следния блок с код в .ftpaccess файл в тази директория:
    
    <Limit WRITE>
    AllowUser allowed_user_1,allowed_user_2
    DenyAll
    </Limit>
    Важно: Тъй като .ftpaccess файловете не работят рекурсивно, трябва да добавите отделен .ftpaccess файл във всички директории, където искате да приложите зададената настройка.
    
    
  • смесена кофигурация
    
    Можете да добавите FTP достъп до различни команди за различни FTP потребители, с което можете да създавате сложни конфигурации. Например:
    – един потребител (напр. allowed_user_1) с достъп за четене на файлове и разглеждане на директории, но без достъп за създаване на файлове и директории;
    – друг потребител (напр. allowed_user_2) без достъп за четене на файлове и разглеждане на директории, но с достъп за създаване на файлове и директории;
    – трети потребител (напр. allowed_user_3) с пълен достъп.
    
    Добавете следния код в .ftpaccess файл в директорията, където желаете да постигнете гореописаната конфигурация:
    
    <Limit READ>
    AllowUser allowed_user_1,allowed_user_3
    DenyAll
    </Limit>
    
    <Limit WRITE>
    AllowUser alloweduser_2,allowed_user_3
    DenyAll
    </Limit>
    Важно: Тъй като .ftpaccess файловете не работят рекурсивно, трябва да добавите отделен .ftpaccess файл във всички директории, където искате да приложите зададената настройка.

  4. Позволяване само на качване на файлове

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

  <Limit ALL>
  DenyAll
  </Limit>
  
  <Limit CDUP CWD XCWD XCUP PWD>
  AllowAll
  </Limit>
  
  <Limit STOR STOU>
  AllowAll
  </Limit>

  Директорията, съдържаща .ftpaccess файла няма да е видима, така че трябва да използвате някой от описаните по-долу начини, за да я достъпите:

  • Въведете пълния път до директорията, съдържаща .ftpaccess файла, ръчно във Вашия FTP клиент.
  • Настроите директорията, съдържаща .ftpaccess файла, за “начална” във Вашия FTP клиент.
  • Зададете директорията, съдържаща .ftpaccess файла, като главна (root) директория за FTP потребителите чрез раздел “FTP потребители” на хостинг Контролния Панел. Можете да намерите повече информация за този раздел в статията ни “FTP Manager“.

  Важно: Тъй като .ftpaccess файловете не работят рекурсивно, трябва да добавите отделен .ftpaccess файл във всички директории, където искате да приложите зададената настройка.

  5. Забраняване на достъп до дадена директория за определени FTP потребители

  Ако желаете да забраните достъпа на определени FTP потребители (напр. restricted_user_1 и restricted_user_2) до дадена директория, използвайте следния код в .ftpaccess файл в съответната директория:

  <Limit ALL>
  DenyUser restricted_user_1,restricted_user_2
  </Limit>

  Важно: Тъй като .ftpaccess файловете не работят рекурсивно, трябва да добавите отделен .ftpaccess файл във всички директории, където искате да приложите зададената настройка.

  6. Разрешаване на достъп само за определени FTP потребители

  За да позволите достъп до директория само за определени FTP потребители (напр. allowed_user_1 и allowed_user_2), трябва да добавите следния блок с код в .ftpaccess файл в директорията:

  <Limit ALL>
  AllowUser allowed_user_1,allowed_user_2
  DenyAll
  </Limit>

  Важно: Тъй като .ftpaccess файловете не работят рекурсивно, трябва да добавите отделен .ftpaccess файл във всички директории, където искате да приложите зададената настройка.

  7. Позволяване на изтриването на файлове само от определени IP адреси или мрежи

  Ако желаете да позволите изтриването на файлове в директория само от определени IP адреси (напр. 1.2.3.4) и мрежи (напр. всички IP адреси, заповащи с 5.6.7), добавете следния код в .ftpaccess файл в тази директория:

  <Limit DELE>
  Allow from 1.2.3.4
  Allow from 5.6.7.
  DenyAll
  </Limit>

  Важно: Тъй като .ftpaccess файловете не работят рекурсивно, трябва да добавите отделен .ftpaccess файл във всички директории, където искате да приложите зададената настройка.

  8. Ограничаване промяната права за достъп за определени FTP потребители

  Можете да добавите парава за промяна на правата за достъп на файлове и директории в дадена директория само за определени FTP потребители (напр. allowed_user_1 и allowed_user_2), добавяйки този код в .ftpaccess файл в директорията:

  <Limit SITE_CHMOD>
  AllowUser allowed_user_1,allowed_user_2
  DenyAll
  </Limit>

  FTP потребителите (напр. allowed_user_1 и allowed_user_2) ще могат да променят правата за достъп на техните файлове и директории, а всички останали FTP потребители няма да могат променят правата за достъп на нито един файл или директория, дори и на тези, които са тяхна собственост.

  Важно: Тъй като .ftpaccess файловете не работят рекурсивно, трябва да добавите отделен .ftpaccess файл във всички директории, където искате да приложите зададената настройка.

• Mod_security2 е модул на Apache 2, известен още като защитна стена за уеб приложения, който блокира определени заявки до уеб сървъра, като се ползва списък от предварително зададени правила. Тези правила включват блокиране на заявки, свързани с популярни атаки срещу сървъри, както и блокиране на заявки към уязвим софтуер. Тази допълнителна мярка за сигурност е активирана по подразбиране на нашите сървъри, тъй като се стремим да защитим максимално сайтовете на нашите клиенти от хакерски атаки. Възможно е определени легитимни заявки към сървъра също да бъдат блокирани, ако съвпаднат с определено правило. Когато това се случи, посетителят вижда грешката 412 Request Blocked (precondition failed).

  Деактивиране на mod_security2 за XML-RPC файлове

  Протоколът XML-RPC се използва от някои модули на WordPress, за да комуникира с външни ресурси. Най-популярните примери за това са разширението Jetpack и официалните мобилни приложения на WordPress. Всички IP адреси, използвани от Jetpack, са добавени към списък с разрешени адреси, така че всички заявки от тях към xmlrpc.php файлове няма да бъдат блокирани от mod_security2. За повече информация как да разрешите достъпа до този файл от раздел “WordPress мениджър” в Контролния панел, разгледайте нашата статия Разрешаване на достъп до XML-RPC.

  Ако сайтът Ви използва xmlrpc.php файл, но не е базиран на WordPress, Вие можете да деактивирате mod_security2 чрез добавяне на следното съдържание в .htaccess файла на Вашия сайт:
  
  <IfModule security2_module>
  SecRuleRemoveById 114
  </IfModule>
  
  Ако Вашият сайт няма .htaccess файл, можете лесно да го създадете чрез раздел Файлове на Контролния панел. Имайте предвид, че зададените настройки ще важат само за директорията, в която се намира .htaccess файла, както и нейните поддиректории.
  
  

  Откриване на mod_security2 правило, което генерира грешка 412

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

  1. Отворете хостинг Контролния панел > раздел “Логове” > подраздел “HTTP логове в реално време“.
  2. Изчакайте една минута, за да започнат да се показват логовете в реално време в подраздел “HTTP логове в реално време“.
  3. Отворете страницата на Вашия сайт, където се показва грешката 412.
  4. Проверете екрана “Логове за грешки” в подраздел “HTTP логове в реално време“, където трябва да видите съобщение за грешка, подобно на следното:
     
     example.com [Fri Aug 13 14:46:30 2021] [error] [pid 9179] apache2_util.c(273): [client YOUR_IP_ADDRESS:59893] [client YOUR_IP_ADDRESS] ModSecurity: Access denied with code 412 (phase 2). Match of “ipMatchFromFile /apache/conf/includes/mod-security-jetpack-ip-whitelist.txt” against “REMOTE_ADDR” required. [file “/apache/conf/includes/mod_security2.conf”] [line “42”] [id “114”] [hostname “example.com”] [uri “/xmlrpc.php”] [unique_id “YRZblp0P33pV7fcztwccfAAAAQE”]

  Конкретното mod_security2 правило и файлът, които генерират грешката, ще бъдат показани в полетата id и uri на съобщението за грешка. В “Match” частта от mod_security2 съобщението, ще откриете обяснение на конкретното правило. В дадения по-горе пример достъпът до xmlrpc.php файлът е блокиран от mod_security2 правилото с идентификационен номер (id) 114, защото достъпът до файла е позволен само от IP адресите на Jetpack.

  Деактириване на отделно правило

  По подразбиране, някои възможно зловредни ботове са блокирани на нашите сървъри с mod_security2 правила. Това е списъкът с някои блокирани ботове, както и техните идентификационни номера (ID):

  “Havij” id:350
  “^BOT/0.1” id:354
  “^Mozilla\/4\.0 \(compatible; MSIE 6\.0; Windows NT 5\.1;?( SV1)?;?\)$” id:373
  “^Mozilla\/3\.0 \(compatible; Indy Library\)$” id:392
  “sqlmap” id:398
  “DatabaseDriverMysql” “id:401”
  “BUbiNG” id:406
  “MauiBot” id:407
  “MJ12bot” id:408
  “BLEXBot” id:409
  “DotBot” id:410
  “MegaIndex” id:412

  Ако желаете да разрешите достъпа до сайта Ви от някой от тези ботове, можете да деактивирате съответното mod_security2 правило в .htaccess файл в главната директория на Вашия сайт. Трябва да използвате директивата SecRuleRemoveById, последвана от идентификационния номер (ID) за съответното правило. Например, за да позволите достъп до сайта Ви от бота DotBot (който е блокиран с mod_security2 правило с идентификационен номер 410), трябва да добавите следния код към .htaccess файла на Вашия сайт:

  <IfModule security2_module>
  SecRuleRemoveById 410
  </IfModule>

  Деактивиране на mod_security2

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

  Като алтернатива можете да спрете функциите на mod_security2 само в директорията, в която се намира скриптът, чието изпълнение предизвиква грешка. За да деактивирате mod_security2, създайте .htaccess файл в съответната директория със следното съдържание:
  <IfModule security2_module>
  SecRuleEngine Off
  SecRequestBodyAccess Off
  </IfModule>

• Можете да следите логовете за достъп и за грешки в почти реално време използвайки секцията Логове -> HTTP логове в реално време в контролния панел на хостинг акаунта. Записите може да се появяват с малко закъснение в интерфейса. Когато отворите интерфейса за първи път, логовете започват да се генерират след около минута. Логовете ще спрат да се генерират шест часа след като затворите интерфейса и ще започнат да се генерират отново, когато пак отворите интерфейса.

• Можете да търсите информация в логовете на пощенския сървър на страницата Логове -> E-mail логове в Контролния панел на хостинг акаунта си. Тези логове съдържат информация за всички съобщения, които са доставени от нашите сървъри.

  Повече информация за формата на логовете има в статията Формат на логовете на електронната поща.

• 1. Формат на лог файловете
  
  Всеки ред в лог файловете на уеб сървъра Apache на нашите машини се състои от следните полета:
  
  

  HOSTNAME

  IP

  –

  HTTP USER

  TIME

  REQUEST

  STATUS CODE

  SIZE

  REFERRER

  USER AGENT

  
  Обяснение на всяко едно поле можете да намерите в долната таблица:
  
  

  HOSTNAME	Името на вашия под/домейн, към който е направено запитването
  IP	IP адресът, от който е направено запитването
  –	Не се използва от сървъра
  HTTP USER	Тук се изписва потребителското име, използвано при HTTP оторизация
  TIME	Показва кога е обработено запитването от сървъра – точната дата, час и времевата зона на сървъра
  REQUEST	Показва какъв метод на запитването е използван – най-често GET или POST, последван от ресурса, за който е направено запитването, и използвания протокол – най-често “HTTP/1.1”
  STATUS CODE	Статус кодът, който сървърът е изпратил на клиента. Всички кодове, започващи с 2, показват успешна обработка от страна на сървъра. Започващите с 3 – пренасочване, с 4 – грешка, причинена от клиента и 5 – грешка от страна на сървъра. Пълен списък можете да намерите в HTTP спецификацията (RFC2616 секция 10).
  SIZE	Големината в байтове на изпратеното към клиента съдържание от страна на сървъра
  REFERRER	Ако в запитването се съдържа REFERER хедър, тук ще се изписва страницата, от която идва клиента
  USER AGENT	Информация за браузъра на клиента, направил запитването към сървъра

  
  Имайте предвид, че след обработка от системата всички запитвания към определен под/домейн попадат във файл [името на под/домейна].log и съответното поле за HOSTNAME в този лог файл се отстранява. За нагледност полето HOSTNAME е оставено в следващите примери.
  
  2. Примери
  
  • Ето един пример, илюстриращ как потребител търси в google.com ключовите думи test и example, търсачката му показва в резултатите www.example.com и потребителят натиска с мишката линка към http://www.example.com/index.php:
  www.example.com 64.14.68.138 – – [07/Jul/2019:08:38:50 -0400] “GET /index.php HTTP/1.1” 200 3242 “http://www.google.com/search?hl=en&q=test+example&btnG=Search” “Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)”Обяснение на всяко едно поле можете да намерите в долната таблица:
  
  

  HOSTNAME	www.example.com	Запитването е направено към www.example.com
  IP	64.14.68.138	IP адресът, от който е направено запитването е 64.14.68.138
  –	–	–
  HTTP USER	–	Потребителят не е използвал потребителско име и парола, тъй като ресурсът не е защитен с HTTP оторизация
  TIME	[07/Jul/2019:08:38:50 -0400]	Обработването на тази заявка е завършено в 8:38:50 GMT-4 часа на 7.7.2019
  REQUEST	“GET /index.php HTTP/1.1”	Mетодът на запитването е GET, ресурсът е index.php, а използваният протокол HTTP/1.1
  STATUS CODE	200	Статус код 200 показва, че обработката от страна на сървъра е била успешна
  SIZE	3242	Големината на изпратеното съдържание е 3242 байта
  REFERRER	“http://www.google.com/search?hl=en&q=test+example&btnG=Search”	Потребителят е попаднал на http://www.example.com/index.php чрез търсене в google на ключовите думи test и example
  USER AGENT	“Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)”	Клиентът използва за браузър Mozilla Firefox, което се разбира от низа Firefox

  
  
  • Създали сте поддомейна protected.example.com, след това сте използвали секцията “Пренасочване” в Контролния панел, за да пренасочите protected.example.com към някой друг адрес – за повече информация как можете да направите това вижте статията Пренасочване. След това сте използвали секцията “Защити” в Контролния панел, за да защитите с потребителско име и парола поддомейна protected.example.com – за повече информация как можете да направите това вижте статията Защити.
  
  Потребител изписва в своя браузър Internet Explorer адреса http://protected.example.com. На потребителя се извежда диалогов прозорец, в който той въвежда своето потребителско име alloweduser и съответната парола за достъп до protected.example.com. След успешна оторизация той бива препратен към зададения в секцията “Пренасочване” адрес. В лог файла на Apache се появяват два реда.
  
  Първи ред:

  protected.example.com 64.14.68.139 – – [07/Jul/2019:09:40:10 -0400] “GET / HTTP/1.1” 401 409 “-” “Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)”

  Ето по-интересните части от първи ред:

  HTTP USER	–	Потребителското име липсва тук, тъй като сървърът изпраща с това запитване изискването за оторизация
  STATUS CODE	401	Сървърът индикира с този статус код, че достъпът до protected.example.com изисква потребителско име и парола
  USER AGENT	“Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)”	Клиентът използва за браузър Internet Explorer, което се разбира от низа MSIE

  Втори ред:

  protected.example.com 64.14.68.139 – alloweduser [07/Jul/2019:09:40:32 -0400] “GET / HTTP/1.1” 302 237 “-” “Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)”
  

  Ето по-интересните части от втори ред:

  HTTP USER	alloweduser	Потребителското име, използвано за достъп до ресурса, е alloweduser
  STATUS CODE	302	Сървърът индикира с този статус код, че protected.example.com е пренасочен към друг адрес

• Лог файловете на Apache за уеб достъпа до вашия акаунт, както и FTP логовете, се намират в папката /home/%USER%/logs на акаунта.

  Тази папка е достъпна през FTP. За да стигнете до нея, трябва да използвате вашия главен FTP потребител, и когато се логнете с FTP програмата си, да промените текущата FTP директория на /logs. В тази папка ще намерите логовете за уеб достъп (Apache) и FTP.

  Можете да видите как да следите логовете за грешки и за достъп на уеб сървъра в почти реално време в статията HTTP логове в реално време. 

  Логовете на имейл сървъра не могат да бъдат свалени. Можете обаче да търсите информация за доставените съобщения на кутиите в хостинг акаунта си на страницата Контролен панел -> Логове. Има повече информация за търсене на определени съобщения в статията Търсене на писма в логовете на сървъра за електронна поща.

  
  
  

• Важно: На всички хостинг планове поддържаме технологията FPM с OPcache, която работи по-добре от FastCGI (която се поддържа само на VPS плановете) и може да се пусне изключително лесно от Контролния панел. Има повече информация за това в статията Поддържани PHP версии. Тъй като е възможно поддръжката на FastCGI да бъде спряна в бъдеще, ако вече използвате FastCGI, можете да намерите информация как да преминете към FPM в статията Преминаване от FASTCGI на FPM.

   

  За да пуснете успешно FastCGI+OPcache, в следващите инструкциите, задължително заменете:

  USERNAME с реалното потребителско име на Вашия хостинг акаунт (можете да намерите своето потребителско име в горния ляв ъгъл на Вашия хостинг Контролен панел)

   

  FastCGI е начин за ускоряване на достъпа до често посещавани страници на сайта. FastCGI работи по такъв начин, че един процес обработва множество заявки преди да бъде спрян. Това премахва нуждата от стартиране на нов PHP процес при всяка нова заявка към сайта, което намалява времето за изпълнение. Освен това FastCGI позволява на OPcache да работи – този механизъм кешира предварително компилирания от приложенията байткод, като по този начин PHP не трябва отново и отново да компилира байткод за едни и същи PHP приложения. FastCGI+OPcache е най-бързото решение за обработка на множество заявки и подобряване на общата производителност на сайта.

  За акаунти, които поддържат FastCGI, можете да пуснете тази технология за Вашия главен уебсайт (www.domain.com) с три прости стъпки:

  Стъпка 1)

  Създайте файл /home/USERNAME/www/www/.ht-fcgi-php-wrapper от раздел “Файлове” на Вашия хостинг Контролен панел. Уверете се, че файлът има необходимите права за изпълнение (съветваме Ви да сложите права 775 на файла). След като файлът е създаден успешно и има необходимите права за изпъление, добавете в него следния код:

  #!/bin/bash
  
  # memory limit in kbytes
  ulimit -v 573440
  
  # do not lower this limit or you may start getting sporadic 500 server errors
  export PHP_FCGI_MAX_REQUESTS=10000
  
  # disable PHP child process management
  export PHP_FCGI_CHILDREN=0
  
  exec /usr/local/bin/php74.cgi -c /home/USERNAME/www/www/php.ini

  Важно: Ако файлът /home/USERNAME/www/www/php.ini не съществува, Ви съветваме да го създадете от раздел “Файлове” на Вашия хостинг Контролен панел и добавите съдържанието по подразбиране за php.ini файлове на нашите сървъри от съображение за съвместимост.

  В тази първа стъпка е важно да се отбележи, че изборът на PHP версията, която приложението Ви ще ползва, се прави като се посочи пътят до CGI скрипта (например php74.cgi). Това се прави в последния ред от кода, споменат по-горе.

  Можете да избирате от следните PHP версии, според предпочитаната от Вас:

  PHP 7.4 (препоръчана):

  exec /usr/local/bin/php74.cgi -c /home/USERNAME/www/www/php.ini

  PHP 7.3:

  exec /usr/local/bin/php73.cgi -c /home/USERNAME/www/www/php.ini

  PHP 7.2:

  exec /usr/local/bin/php7.cgi -c /home/USERNAME/www/www/php.ini

  PHP 7.1:

  exec /usr/local/bin/php71.cgi -c /home/USERNAME/www/www/php.ini

  PHP 5.6 (остаряла):

  exec /usr/local/bin/php56.cgi -c /home/USERNAME/www/www/php.ini

  PHP 5.3 (остаряла):

  exec /usr/local/bin/php53.cgi -c /home/USERNAME/www/www/php.ini

  Важно: Убедете се, че сте заместили USERNAME с реалното потребителско име на Вашия хостинг акаунт, което можете да откриете в горния ляв ъгъл на Вашия хостинг Контролен панел.

  Стъпка 2)

  Създайте /home/USERNAME/www/www/.htaccess и добавете в него следния код, или добавете кода към съществуващия .htaccess файл:

  <IfModule mod_fcgid.c>
  <FilesMatch "\.php$">
  AddHandler fcgid-script .php
  FcgidWrapper /home/USERNAME/www/www/.ht-fcgi-php-wrapper .php
  </FilesMatch>
  </IfModule>

  Важно: Убедете се, че сте заместили правилно USERNAME с реалното потребителско име на Вашия хостинг акаунт, което можете да намерите в горния ляв ъгъл на Вашия хостинг Контролен панел. Също проверете своя .htaccess файл за други AddHandler директиви и ги закоментирайте/изтрийте.

  Стъпка 3)

  Включете OPcache като добавите следния код в php.ini файла за Вашия главен уебсайт, използвайки раздел “PHP настройки” в хостинг Контролния панел:

  ;Enabling OPcache
  [opcache]
  zend_extension = opcache.so
  opcache.enable = 1
  opcache.memory_consumption = 128
  opcache.max_accelerated_files = 10000
  opcache.revalidate_freq = 60

   

  Важно: Ако искате да включите FastCGI за поддомейн (example.domain.com), трябва да създадете файла /home/USERNAME/www/example/.ht-fcgi-php-wrapper , промените последния ред в него, така че да се използва основния php.ini файл на поддомейна (напр. /home/USERNAME/www/example/php.ini) и да създадете или редактирате файла /home/USERNAME/www/example/.htaccess. Пътят до .ht-fcgi-php-wrapper, указан в .htaccess файла, също трябва да бъде коригиран.

  Ако срещнете трудности с FastCGI, можете да се свържете с отдела за техническа поддръжка и да получите помощ.

• Основен IP адрес
  

  Можете да видите основния IP адрес на сървъра в страничната лента Информация, раздел IP адреси:
  
  

  Основният IP адрес на сървъра се използва:

  • за изходящ e-mail. Ето защо ако използвате нашия e-mail сървър за изходяща поща, SPF записите за Вашите домейни трябва да съдържат и основния IP адрес на сървъра.
  • изходящи връзки от сървъра. Ето защо ако използвате софтуер на Вашия акаунт, който се свързва с отдалечена услуга, достъпът до която е ограничен по IP адрес, трябва да добавите този IP адрес в списъка с разрешени адреси за достъп.
  • ако Вашия акаунт не разполага с други IP адреси, всички A записи на Вашите домейни ще сочат към този адрес.

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

  Вашите домейни трябва да сочат към основния IP адрес на акаунта. Ако домейните Ви използват нашите DNS сървъри, неговите DNS записи могат да бъдат редактирани в раздел DNS записи на Контролния панел. Ако Вашият акаунт разполага с повече от един IP адрес (например заради инсталацията на няколко SSL сертификата), един от тях ще бъде маркиран като основен. Това е IP адресът, към който ще бъдат насочени всички DNS записи, в случай че използвате функцията Възстанови в раздел DNS записи.
  
  

  Чужди DNS сървъри

  Ако Вашият домейн не използва DNS сървърите на хостинг сървъра, имайте предвид:

  • ако акаунтът Ви разполага с IP адрес, домейните Ви трябва да сочат към него, в противен случай – към основния IP адрес на сървъра.
  • ако домейнът Ви разполага със SPF запис и използвате нашия сървър за изходяща поща, SPF записът трябва да съдържа и основния IP адрес на сървъра.

   

  Промяна на IP адресите на сървъра

  Въпреки че нашите сървъри използват статични IP адреси, е възможно от време на време IP адресите на сървъра да бъдат сменени.
  
  Обикновено процедурата по смяна на IP адресите протича по следния начин:

  • ще зачислим нови IP адреси на сървъра, които ще работят паралелно със старите. По този начин няма да има смущения в услугите на сървъра.
  • в разделите DNS записи и Информация за сървъра на Контролния панел ще се появи информация за IP адресите, които ще бъдат сменени.
  • ще уведомим нашите клиенти относно промените и ще им дадем достатъчно време да преминат към новите IP адреси, в случай че ги използват за достъп до услугите на сървъра. Ако даден домейн използва външни (не наши) DNS сървъри, клиентът ще трябва сам да актуализира IP адресите в тях.
  • ще обявим датата, на която старите IP адреси ще спрат да работят. До тази дата клиентите е нужно да са направили необходимите актуализации.

  
  В случай че Вашите домейни използват DNS сървърите на хостинг сървъра и Вие не използвате нито един от засегнатите IP адреси във Ваша програма, не е нужно да правите нищо във връзка с промяната на IP адресите.

• На нашите сървъри всеки потребителски акаунт може да използва до 20 конкурентни процеса едновременно. Когато имате 20 едновременни процеса, които не са приключили изпълнението си навреме и в същия момент се опитате да стартирате нов процес, поради превишаването на лимита ще се появи съобщението, че не може да бъде стартиран нов процес:
  
  
  
  Страницата ще се презареди автоматично след 10 секунди в нов опит за стартиране на процес.
  
  За да предотвратите такива съобщения, трябва да оптимизирате цялостното изпълнение на вашите скриптове/MySQL заявки, така че те да приключват достатъчно бързо след стартирането им.