Сървърни/Системни Спецификации

За да предложим на клиентите си изключителна производителност и надеждност, които отговарят и на най-високите изисквания, използваме само най-мощните и надеждни сървърни компоненти за хардуерната конфигурация на нашите сървъри. Всеки наш хостинг сървър разполага с два многоядрени (до 18 ядра) Xeon процесора, до 1024 GB 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). Свържете с Вашия хостинг доставчик, ако не виждате раздела Уеб приложения във Вашия хостинг Контролен панел, но желаете да се възползвате от поддръжката на уеб приложения на сървърите.

Изброили сме някои от най-често срещаните причини, поради които можете да получите "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 скрипт, то проверете какъв системен път използвате в началото му. За да видите къде се намират интерпретаторите на изброените езици на файловата система на сървъра, използвайте секцията "Информация за сървъра" във вашия Контролен панел - за повече информация погледнете статията Информация за сървъра.

По-долу можете да откриете описание на най-често срещаните грешки от Apache уеб сървъра: 401 Authorization RequiredТази грешка показва, че посетителят на сайта се опитва да достъпи страница, защитена с парола, без да е предоставил комбинация от правилни потребителско име и парола. 403 ForbiddenТази грешка означава, че страницата, която се опитва да достъпи посетителя на сайта, е забранена за посещения. Това ограничение може да бъде в сила от специално правило в настройката на сървъра или специални права на файла. Следното правило в .htaccess файл би предизвикало така грешка за посетител с IP адрес 1.2.3.4: deny from 1.2.3.4 Грешката може да бъде предизвикана и от липсващи права за прочитане на файла, което би попречило на уеб сървъра да отвори файла и да обработи неговото съдържание за посетителя на сайта. 404 Not FoundГрешката с код "404" индикира, че файлът не съществува на сървъра. 412 Precondition FailedТази грешка се показва, когато се е активирала защитата на модула "mod_security" на нашите сървъри. Можете да научите повече за тази защита в статията ни "Грешка "412 Precondition Failed" - използване на mod_security2". 500 Internal Server ErrorГрешката с код 500 е обобщаваща и индикира проблем с обработката на заявката от страна на сървъра. Тя може да бъде причинена от много неща, като неправилна настройка в .htaccess файл, невъзможност за изпълнение на скрипт, грешни настройки на софтуерно приложение на сайта и др. Повече възможни причини за тази грешка има в статията ни "Сървърна грешка 500 (Internal Server Error) ". Възможно е да има по-подробна информация за такива грешки в логовете на сървъра. Можете да видите информацията от тези логове чрез раздел Логове в Контролния панел.

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 спецификацията (RFC 9110 секция 15). 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 е пренасочен към друг адрес

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

Лог файловете на Apache за уеб достъпа до вашия акаунт, както и FTP логовете, се намират в папката /home/%USER%/logs на акаунта. Тази папка е достъпна през FTP. За да стигнете до нея, трябва да използвате вашия главен FTP потребител, и когато се логнете с FTP програмата си, да промените текущата FTP директория на /logs. В тази папка ще намерите логовете за уеб достъп (Apache) и FTP. Можете да видите как да следите логовете за грешки и за достъп на уеб сървъра в почти реално време в статията HTTP логове в реално време.  Логовете на имейл сървъра не могат да бъдат свалени. Можете обаче да търсите информация за доставените съобщения на кутиите в хостинг акаунта си на страницата Контролен панел -> Логове. Има повече информация за търсене на определени съобщения в статията Търсене на писма в логовете на сървъра за електронна поща.

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

"Mod_gzip" е модул за Apache 1.3 уеб сървъра. Тъй като ние не използваме Apache 1.3 на нашите сървъри, този модул не е наличен с нашата хостинг услуга. На нашите сървъри използваме Apache 2, където функционалността на модула "mod_gzip" се покрива от модула "mod_deflate". Можете да научите повече за използването на модула "mod_deflate" в статията ни "Използване на mod_deflate".

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_speling е модул на уеб сървъра Apache. Файловата система на Linux е чувствителна към главни и малки букви. Mod_speling цели да разреши проблеми с имената на файлове, в които има комбинация от главни и малки букви. Можете да срещнете такива проблеми, ако трансферирате при нас сайт, който е създаден за сървър базиран на Windows, или ако сте разработили сайта си на програма на Windows.   Как да използвам mod_speling? За да използвате mod_speling е нужно да създадете файл с име .htaccess (обърнете внимание на точката пред името на файла) със следното съдържание:  <IfModule mod_speling.c>CheckSpelling onCheckCaseOnly on</IfModule> Съхранете този файл в директорията, в която искате да използвате mod_speling. Имайте предвид, че .htaccess файловете имат рекурсивно действие - това означава, че настройките са активни не само за директорията, където се намира .htaccess файла, но и за нейните поддиректории. 

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 и текстови файлове.

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 linking2.8 Блокиране на достъпа от определен IP адрес или мрежа2.9 Уведомяване на посетителите за текуща реконструкция2.10 Блокиране на достъпа до сайта според часа2.11 Принудително използване на www.your_domain.com2.1 Забрана за достъп до определени файлове ^Със следния код можете да забраните достъпа до файлове с определени разширения - в този пример става дума за всички файлове, които имат разширение .txt. В случая посетителите ще виждат страница с грешка "403 Forbidden" вместо съдържанието на .txt файла. <Files ~ "\.txt$">Order Allow,DenyDeny from All</Files>А ако искате да забраните достъпа например до всички .txt .doc .rtf .log .fla .psd файлове, използвайте следния код:<FilesMatch "\.(txt|doc|rtf|log|fla|psd)$">Order Allow,DenyDeny from all</FilesMatch>2.2 Добавяне на Content-Type хедър към вашите страници ^За да добавите Content-Type хедър, така че сървърът да съобщава за кодирането на всяка ваша страница на браузъра, използвайте директивата AddDefaultCharset. Ето два примера:AddDefaultCharset UTF-8AddDefaultCharset ISO-8859-12.3 Използване на определена времева зона ^Чрез следния ред можете да принудите PHP скриптовете ви да използват вашата времева зона вместо тази на сървъра: SetEnv TZ Europe/London Пълен списък с поддържаните часови зони можете да намерите на следния адрес: http://php.net/manual/bg/timezones.php2.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.htmlErrorDocument 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 OnRewriteCond %{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 OnRewriteCond %{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 OnRewriteCond %{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 OnRewriteCond %{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,denydeny from  64.14.68.138deny from 64.14.68.139allow from all• Блокиране на достъпа от определен определена мрежаМожете да забраните и цяла мрежа. За да блокирате например всички IP адреси, започващи с 64.14.68. (т.е. мрежата 64.14.68), използвайте следния код:order allow,denydeny from 64.14.68.allow from all• Блокиране на достъпа от всички IP адреси и мрежиАко желаете да забраните достъпа на всички, използвайте следния ред във вашия .htaccess файл:deny from allОсвен IP адреси, в .htaccess файла можете да използвате и имена на домейни:deny from example.comА за да блокирате достъпа от всички поддомейни на example.com, използвайте:deny from .example.com2.9 Уведомяване на посетителите за текуща реконструкция ^Ако сте решили, че ще правите реконструкция на вашия сайт и желаете вместо да блокирате достъпа до нея, да позволите на посетителите да разберат, че сайта ви подлежи на реконструкция, е нужно да изготвите един файл maintenance.html в главната ви директория www. Неговотo съдържание ще се показва на посетителите, докато сайтът ви не е достъпен. След това добавете следните редове в .htaccess файла, който се намира в главната директория www: RewriteEngine OnRewriteCond %{REQUEST_URI} !/maintenance.html$RewriteRule .* /maintenance.html [R=307,L]2.10 Блокиране на достъпа до сайта според часа ^Ако желаете посетителите ви да имат достъп до вашия сайт само в работното ви време (7:00 - 19:00 ч.), използвайте следния код:RewriteEngine OnRewriteCond %{TIME_HOUR}%{TIME_MIN} >1900 [OR]RewriteCond %{TIME_HOUR}%{TIME_MIN} <0700 RewriteRule ^.*$ - [F,L]Ако желаете да забраните достъп до сайта ви в обедната си почивка, използвайте следния код, който ще забрани достъпа от 12:00 до 12:59 през деня:RewriteEngine OnRewriteCond %{TIME_HOUR} ^12$RewriteRule ^.*$ - [F,L]2.11 Принудително използване на www.your_domain.com ^Ако желаете посетителите на вашия сайт винаги да бъдат препращани към www.your_domain.com, когато направят заявка до your_domain.com или до някой от паркираните ви домейни, използвайте следния код:RewriteEngine OnRewriteCond %{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 команди в дадена директория и всички директории под нея. По-долу можете да откриете списък с групите команди, най-използваните 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 файл: Блокиране на FTP достъп• от определени IP адреси или мрежи• отвсякъде (всички IP адреси и мрежи)• отвсякъде освен определени IP адреси и мрежи Забраняване триенето на файлове и директории Забраняване качването на файлове и създаването на директории• за всички без определени FTP потребители• смесена кофигурация Позволяване само на качване на файлове Забраняване на достъп до дадена директория за определени FTP потребители Разрешаване на достъп само за определени FTP потребители Позволяване на изтриването на файлове само от определени IP адреси или мрежи Ограничаване промяната права за достъп за определени FTP потребители 1. Блокиране на FTP достъп от определени IP адреси или мрежиЗа да блокирате FTP достъпа до директория от определени IP адреси (напр. 1.2.3.4) или мрежи (напр. всички IP адреси, започващи с 5.6.7), добавете следния блок с код към .ftpaccess файл в тази директория:<Limit ALL>Order allow,denyDeny from 1.2.3.4Deny from 5.6.7.</Limit>   отвсякъде (всички IP адреси и мрежи)Можете напълно да ограничите FTP достъпа до директория, добавяйки следния блок с код в .ftpaccess файл в директорията:<Limit ALL>Order allow,denyDeny from all</Limit>   отвсякъде освен определени IP адреси и мрежиЗа да ограничите FTP достъпа до директория за всички освен определени IP адреси (напр. 1.2.3.4) или мрежи (напр. всички IP адреси, започващи с 5.6.7), използвайте следния код в .ftpaccess файл в тази директория:<Limit ALL>Order allow,denyAllow from 1.2.3.4Allow from 5.6.7.Deny from all</Limit> 2. Забраняване триенето на файлове и директории Ако желаете да забраните триенето на файлове и директории за всички потребители освен за един (напр. allowed_user), използвайте следния код в .ftpaccess файла на директорията: <Limit DELE RMD XRMD>AllowUser allowed_userDenyAll</Limit> 3. Забраняване качването на файлове и създаването на директории за всички без определени FTP потребителиАко желаете да позволите на всички FTP потребители да виждат съдържанието на директория, но да забраните качването на файлове и създаването на директории в нея за всички с изключение на два FTP потребителя (напр. allowed_user_1 и allowed_user_2), добавете следния блок с код в .ftpaccess файл в тази директория:<Limit WRITE>AllowUser allowed_user_1,allowed_user_2DenyAll</Limit> смесена кофигурацияМожете да добавите FTP достъп до различни команди за различни FTP потребители, с което можете да създавате сложни конфигурации. Например:- един потребител (напр. allowed_user_1) с достъп за четене на файлове и разглеждане на директории, но без достъп за създаване на файлове и директории;- друг потребител (напр. allowed_user_2) без достъп за четене на файлове и разглеждане на директории, но с достъп за създаване на файлове и директории;- трети потребител (напр. allowed_user_3) с пълен достъп.Добавете следния код в .ftpaccess файл в директорията, където желаете да постигнете гореописаната конфигурация:<Limit READ>AllowUser allowed_user_1,allowed_user_3DenyAll</Limit><Limit WRITE>AllowUser alloweduser_2,allowed_user_3DenyAll</Limit> 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". 5. Забраняване на достъп до дадена директория за определени FTP потребители Ако желаете да забраните достъпа на определени FTP потребители (напр. restricted_user_1 и restricted_user_2) до дадена директория, използвайте следния код в .ftpaccess файл в съответната директория: <Limit ALL>DenyUser restricted_user_1,restricted_user_2</Limit> 6. Разрешаване на достъп само за определени FTP потребители За да позволите достъп до директория само за определени FTP потребители (напр. allowed_user_1 и allowed_user_2), трябва да добавите следния блок с код в .ftpaccess файл в директорията: <Limit ALL>AllowUser allowed_user_1,allowed_user_2DenyAll</Limit> 7. Позволяване на изтриването на файлове само от определени IP адреси или мрежи Ако желаете да позволите изтриването на файлове в директория само от определени IP адреси (напр. 1.2.3.4) и мрежи (напр. всички IP адреси, заповащи с 5.6.7), добавете следния код в .ftpaccess файл в тази директория: <Limit DELE>Allow from 1.2.3.4Allow from 5.6.7.DenyAll</Limit> 8. Ограничаване промяната права за достъп за определени FTP потребители Можете да добавите парава за промяна на правата за достъп на файлове и директории в дадена директория само за определени FTP потребители (напр. allowed_user_1 и allowed_user_2), добавяйки този код в .ftpaccess файл в директорията: <Limit SITE_CHMOD>AllowUser allowed_user_1,allowed_user_2DenyAll</Limit> FTP потребителите (напр. allowed_user_1 и allowed_user_2) ще могат да променят правата за достъп на техните файлове и директории, а всички останали FTP потребители няма да могат променят правата за достъп на нито един файл или директория, дори и на тези, които са тяхна собственост.

Какво е robots.txt файл? Robots.txt файловете Ви позволяват да информирате обхождащите машини на търсачки и други ботове (роботи) кои URL адреси на сайта Ви трябва и не трябва да бъдат достъпвани според протокола за изключение за роботи (Robots Exclusion Protocol). Можете да го използвате в комбинация със sitemap.xml файл и Robots мета тагове за по-добър контрол над частите на сайта Ви, които трябва да се обхождат от ботове. Файлът robots.txt трябва да се намира в основната директория на сайта. Важно: Правилата в robots.txt файла разчитат на доброволното подчинение на обхождащите машини на търсачки и други ботове, които посещават сайта Ви. Ако желаете изцяло да блокирате достъпа до определени страници или файлове на сайта Ви или да предотвратите изцяло посещенията от определени ботове, тогава Ви съветваме да използвате .htaccess файл. Различни примери за прилагане на такива ограничения са налични в статията ни "Използване на .htaccess". Как да създам robots.txt файл? Някои приложения (напр. Joomla) идват с robots.txt файл по подразбиране, докато други (напр. WordPress) може да създават robots.txt файла си динамично. Динамично създадените robots.txt файлове не съществуват на сървъра, така че промяната им ще е специфична за самото софтуерно приложение, което използвате. За WordPress можете да използвате разширение, което управлява robots.txt файла по подразбиране или да създадете ръчно нов robots.txt файл. Можете да създадете robots.txt файл за Вашия сайт чрез раздел "Файлове" на хостинг Контролния панел. Можете и да създадете robots.txt файл локално на Вашето устройство чрез текстов редактор по Ваш избор и след това да качите файла чрез FTP клиент на Вашия акаунт. Можете да откриете инструкции за настройка на най-популярните FTP приложения в раздел "Качване на файлове" на нашата онлайн документация. Какво мога да използвам в robots.txt файла? Правилата в robots.txt файловете се описват с директиви. Можете да използвате следните директиви в robots.txt файл: User-agent - определя User Agent на бота/обхождащата машина, за която да важи правилото. Ако трябва да разрешите или забраните достъпа за едни и същи директории за ботове с различен User Agent, то може да ги изпишете един след друг. Символът "*" (звезда) може да се използва като wildcard символ, като по този начин правилото ще важи за всеки User Agent. Allow/Disallow - показва дали зададения по-горе User Agent трябва или не трябва да посещава определена директория на домейна. Можете да добавите ограничение за достъпа за различни директории, добавяйки ги на отделен ред. Символът "*" (звезда) може да се използва като wildcard символ. Символът "$" (долар) може да се използва за указване края на директория/URL. Crawl-delay (допълнителен) - инструктира обхождащите машини и ботовете да забавят честотата на обхождане на сайта. Директивата приема цифрова стойност от 1 до 30, което представлява времето на изчакване между отделни заявки в секунди. Тази директива може да се използва за забавяне на обхождането от ботове, които са прекалено агресивни, ако въпросните ботове се подчиняват на директивата. Sitemap (допълнителен) - оказва адреса на sitemap на сайта за обхождащите машини на търсачки.  Ако имате отделни сайтове в поддиректории на главния домейн, може да въведете техните sitemap локации на нов ред. Главните и малки букви се разглеждат като различни символи в стойностите за директивите, така че се уверете, че ги използвате правилно. Например, ако използвате "Googlebot" и "GoogleBot" като User Agent във Вашия robots.txt файл, ще блокирате два различни бота. Коментари в robots.txt файла Можете да използвате символа "#" (диез) за добавяне на коментари с цел по-добра четимост за хора. Символите след "#" се считат за коментар, ако символът е в началото на ред или след правилно дефинирана директива, последвана от интервал. По-долу можете да откриете примери за валидни коментари:# This is a comment on a new line.User-agent: * # This is a comment after the User-agent directive.Disallow: / # This is a comment after the Disallow directive.и за невалидни коментари:// This is not a valid comment.User-agent: Bot# This is not a valid comment as it is not separated with an interval after the User-agent. The matched User-Agent will be "Bot#" and not "Bot".Файлът robots.txt трябва да бъде съдържа UTF-8 символи. Протоколът за изключение на роботи изисква обхождащите машини и ботове да обработват robots.txt файлове с размер от най-малко 500 KiB. Тъй като Google са настроили техните ботове да не обхождат robots.txt файлове по-големи от 500 KiB, Ви съветваме да се опитате да ограничите размера на Вашия robots.txt под 500 KiB. Какво е съдържанието по подразбиране на robots.txt файла? Съдържанието на robots.txt файла ще зависи от Вашия сайт и приложението/скриптовете, които използвате на него. По подразбиране на ботове с всеки User Agent е позволен достъп до всички страници на сайта Ви, освен ако нямате собствен robots.txt файл с други инструкции. Joomla Съдържанието на robots.txt файла за Joomla е наличен в официалната документация и изглежда така:User-agent: *Disallow: /administrator/Disallow: /api/Disallow: /bin/Disallow: /cache/Disallow: /cli/Disallow: /components/Disallow: /includes/Disallow: /installation/Disallow: /language/Disallow: /layouts/Disallow: /libraries/Disallow: /logs/Disallow: /modules/Disallow: /plugins/Disallow: /tmp/ WordPress Robots.txt файлът на WordPress има следното съдържание по подразбиране:User-agent: *Disallow: /wp-admin/Allow: /wp-admin/admin-ajax.phpSitemap: https://YOUR_DOMAIN.com/wp-sitemap.xml Примери Можете да откриете различни примери за употреба на robots.txt файлове по-долу: Как да позволите пълен достъп Как да забраните пълен достъп Как да позволите пълен достъп с изключение на директория или файл Как да позволите пълен достъп освен за определен бот Как да позволите пълен достъп само за определен бот Как да забраните достъп до определен тип файлове Как да забраните достъп до страници със символа долар в името Как да информирате ботовете, че те могат да достъпват целия сайт? Ако сайтът Ви няма няма robots.txt файл, правилото по подразбиране за сайта Ви ще бъде да се позволи пълен достъп до всички страници на домейна Ви за всеки User Agent:User-Agent: *Allow: / Същият ефект може да се постигне и с директивата за забрана на достъп ("Disallow") без да се определи директория за забраната:User-Agent: *Disallow: Как да информирате всички ботове, че не трябва да достъпват сайта Ви? За да забраните достъпа за всички ботове до Вашия сайт, можете да използвате следния код във Вашия robots.txt файл:User-Agent: *Disallow: / Как да информирате ботовете , че могат да достъпват целия сайт без определена директория/файл? Можете да инструктирате ботовете да обхождат целия сайт с изключение на определена директория или файл, използвайки следните директиви във Вашия robots.txt файл:User-agent: *Disallow: /directory/User-agent: *Disallow: /directory/file.html Как да позволите пълен достъп до сайта Ви за всички ботове с изключение на един? Ако желаете да позволите на всички ботове освен един да обхождат целия Ви сайт, тогава използвайте следния код в robots.txt файла на сайта Ви:User-agent: NotAllowedBotDisallow: /В горния пример трябва да замените "NotAllowedBot" с User Agent на бота, който желаете да информирате, че не трябва да обхожда сайта Ви. Как да позволите пълен достъп сайта Ви само за определен бот? За да инструктирате всички ботове освен един да не обхождат сайта Ви, използвайте този код: User-agent: AllowedBotAllow: /User-agent: *Disallow: /В горния пример трябва да замените "AllowedBot" с User-Agent на бота, който желаете да обхожда сайта Ви. Как да информирате ботовете, че не трябва да достъпват определени типове файлове? Добавете следния код към Вашия robots.txt файл, за да инструктирате ботовете, подчиняващи се на правилата в robots.txt файлове, да не обхождат .pdf файлове:User-agent: *Disallow: /*.pdf$ Как да информирате ботовете да не достъпват страници със символа долар в името? Символът долар ("$") има специално значение в robots.txt файловете - той определя края на низа за съвпадение в директивите "Allow" и "Disallow". За да добавите правило, което обхваща страници, съдържащи символа долар в името си, трябва да използвате следния низ от символи като стойност на директивите "Allow" и "Disallow":User-agent: *Disallow: /*$*Ако добавите стойността без последния wildcard символ по този начин:User-agent: *Disallow: /*$всички ботове ще бъдат информирани да не обхождат целия сайт, което може сериозно да навреди на позициите на сайта Ви в търсачките.

Важно: На всички хостинг планове поддържаме технологията 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 kbytesulimit -v 573440# do not lower this limit or you may start getting sporadic 500 server errorsexport PHP_FCGI_MAX_REQUESTS=10000# disable PHP child process managementexport PHP_FCGI_CHILDREN=0exec /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 8.2: exec /usr/local/bin/php82.cgi -c /home/USERNAME/www/www/php.ini PHP 8.1 (препоръчана): exec /usr/local/bin/php81.cgi -c /home/USERNAME/www/www/php.ini PHP 8.0: exec /usr/local/bin/php80.cgi -c /home/USERNAME/www/www/php.ini 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 .phpFcgidWrapper /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.soopcache.enable = 1opcache.memory_consumption = 128opcache.max_accelerated_files = 10000opcache.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, можете да се свържете с отдела за техническа поддръжка и да получите помощ.

Обща информация за 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, можете да се свържете с отдела ни за техническа поддръжка.

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 мениджър" в Контролния панел > раздел "Сигурност". Ако сайтът Ви използва xmlrpc.php файл, но не е базиран на WordPress, Вие можете да деактивирате mod_security2 чрез добавяне на следното съдържание в .htaccess файла на Вашия сайт: <IfModule security2_module>SecRuleRemoveById 114 </IfModule>Ако Вашият сайт няма .htaccess файл, можете лесно да го създадете чрез раздел "Файлове" на Контролния панел. Имайте предвид, че зададените настройки ще важат само за директорията, в която се намира .htaccess файла, както и нейните поддиректории. Откриване на mod_security2 правило, което генерира грешка 412 Ако виждате грешка 412 на определена страница от Вашия сайт, можете много лесно да откриете кое mod_security2 правило я предизвиква. Всичко, което трябва да направите, е да прегледате сървърните логове за грешки за Вашия сайт, следвайки тези стъпки: Отворете хостинг Контролния панел > раздел "Логове" > подраздел "HTTP логове в реално време". Изчакайте една минута, за да започнат да се показват логовете в реално време в подраздел "HTTP логове в реално време". Отворете страницата на Вашия сайт, където се показва грешката 412. Проверете екрана "Логове за грешки" в подраздел "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 OffSecRequestBodyAccess Off</IfModule>

Основен 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 адресите.

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

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

Ако желаете да следите или записвате POST заявките, обработени от Apache уеб сървъра, можете да направите това на нашите сървъри с помощта на модула "mod_security". Всичко, което трябва да направите, е да създадете лог файл и да добавите определено съдържание в .htaccess файл. Повече информация за този метод е достъпна в този уебсайт на англ. език. За да активирате записването на POST заявки на нашите сървъри, следвайте тези стъпки: Създайте лог файл в директорията на сайта Ви. За WordPress инсталация можете да създадете файла в "wp-content" директорията (напр. "~/www/www/wp-content/post.log") чрез тази SSH команда:touch "/home/$USER/www/www/wp-content/post.log" Настройте правата на файла да бъдат "777":chmod 777 "/home/$USER/www/www/wp-content/post.log"Важно: Ако не настроите правата на файла да са "777", Вашият уебсайт ще започне да показва сървърна грешка "500". Добавете следното съдържание в .htaccess файла на сайта Ви (напр. "~/www/www/.htaccess") чрез тази SSH команда:echo -e "\nSecAuditEngine On\nSecRequestBodyAccess On\nSecAuditLogParts ABCIJDEFHZ\nSecRule REQUEST_METHOD "POST" \"id:17,phase:2,t:none,pass,log,auditlog,msg:'Log POST data'\"\nSecAuditLog /home/$USER/www/www/wp-content/post.log" >> "/home/$USER/www/www/.htaccess"Ако желаете, можете да използвате и раздел "Файлове" на хостинг Контролния панел, за да добавите ръчно следния блок с код в .htaccess файла на сайта Ви:SecAuditEngine OnSecRequestBodyAccess OnSecAuditLogParts ABCIJDEFHZSecRule REQUEST_METHOD "POST" "id:17,phase:2,t:none,pass,log,auditlog,msg:'Log POST data'"SecAuditLog /home/$USER/www/www/wp-content/post.logБележка: Използвайки раздел "Файлове", имайте предвид, че трябва да заместите "$USER" с потребителското име на Вашия хостинг акаунт в блока с код. POST заявките могат да съдържат конфиденциална информация, а лог файла с POST заявките ще се съхранява в публично достъпна директория. Можете да ограничите достъпа до лог файла с изпълнение на следната SSH команда:echo -e "\nRedirectMatch 403 ^/wp-content/post.log$" >> "/home/$USER/www/www/.htaccess"Тази команда ще добави следния код към .htaccess файла на сайта Ви, с който посетителите на /wp-content/uploads/post.log файла на сайта Ви ще бъдат пренасочени към страница с грешка 403:RedirectMatch 403 ^/wp-content/post.log$ Това е. Всички POST заявки на сайта Ви вече ще се съхраняват в лог файла, който сте създали.