Uwaga: Poniższy artykuł pomoże Ci w: Jak zapobiegać awariom bloga WordPress i wyłączaniu serwera przez komentarze spamowe WordPress
Po pierwsze, chciałem tylko wyjaśnić, że ten artykuł NIE dotyczy wykrywania i oznaczania komentarzy jako spam. Wtyczka WordPress Akismet już całkiem dobrze sprawdza i filtruje tradycyjne komentarze spamowe WordPress.
Zamiast tego ten post dotyczy tego, jak zapobiegać spamowaniu komentarzami i innym nieuczciwym działaniom awaria twojego serwera i usunięcie twojego bloga.
Zdjęcie autorstwa BoxChain
Jak wspomniałem w moim ostatnim artykule, ruch na moim blogu podwoił się w ciągu ostatniego roku.
I niestety w tym czasie ilość komentarzy spamowych również wzrosła o rząd wielkości.
Aby dać ci wyobrażenie, było kilka dni w grudniu, kiedy co kilka sekund byłem bombardowany ponad 20 komentarzami spamowymi.
Tak, dobrze słyszałeś. Za każdym razem, gdy odświeżałem pulpit nawigacyjny, w filtrze Akismet widziałem 20 lub więcej komentarzy spamowych. W rzeczywistości ilość spamu sprawiła, że wszystkie strony internetowe na moim serwerze były bardzo wolne lub niedostępne przez długi czas w tych dniach.
Problem z WordPressem
Teraz, gdy działa normalnie, mój blog radzi sobie całkiem nieźle przy dużym natężeniu ruchu dzięki wtyczce o nazwie WP Super Cache.
Zasadniczo ta wtyczka tworzy statyczną wersję każdego artykułu na moim blogu, dzięki czemu może być bardzo szybko dostarczona użytkownikowi końcowemu.
Jednak ta wtyczka jest bezradna wobec dużego napływu komentarzy, ponieważ komentarze wymagają, aby serwer za każdym razem wywoływał WordPress w celu przetworzenia komentarzy jeden po drugim.
A ponieważ WordPress jest takim pochłaniaczem zasobów, duży napływ spamu może z łatwością zniszczyć dowolnego bloga, nawet jeśli korzystasz z dedykowanego serwera i używasz wtyczki do buforowania.
Nie ma znaczenia, czy korzystasz z najlepszych filtrów spamu w komentarzach na świecie, wszystkie komentarze spamowe nadal muszą zostać przetworzone przez WordPress, który zajmuje znaczną część zasobów serwera.
Charakterystyka botów spamujących
Wolny lub niedostępny blog to jedno, ale spam z komentarzami wpływa również na inne witryny działające na tym samym serwerze, co jest niedopuszczalne. Po przeprowadzeniu badań na temat botów spamujących odkryłem kilka rzeczy.
- Roboty spamujące zazwyczaj nie akceptują plików cookie
- Boty spamujące mogą zostawić spam w komentarzach w ciągu kilku sekund
- Boty spamowe zwykle nie uruchamiają javascript
Co to oznacza? Mówiąc nietechnicznie, bot spamujący nie zachowuje się jak zwykły użytkownik w przeglądarce internetowej. A kluczem do rozwiązania mojego problemu było natychmiastowe wykrycie bota spamującego i przekierowanie go na stronę błędu zamiast uruchamiania WordPressa.
Na podstawie opisanych powyżej cech mogłem wykrywać roboty spamujące, umieszczając plik cookie na komputerze użytkownika, wyłączając komentarze na wiele sekund po załadowaniu strony lub wymyślając kod javascript do wykrywania spamera.
Rozwiązywanie problemu ze spamem w komentarzach
Po długich rozważaniach wymyśliłem poprawkę, która potajemnie umieszcza plik cookie na komputerze użytkownika za każdym razem, gdy uzyskuje dostęp do strony na moim blogu. Mógłbym wtedy wyszukać ten plik cookie na komputerze użytkownika, zanim zezwolę na przejście komentarza.
Ponieważ bot spamujący zwykle nie akceptuje plików cookie, mogłem go łatwo wykryć i przekierować na statyczną stronę błędu.
Pierwotnie planowałem opublikować mój kod źródłowy w tym wpisie na blogu, który napisałem w javascript (chętnie Ci go wyślę, jeśli jesteś ciekawy), ale po rozmowie z kilkoma innymi blogerami odkryłem, że ten sam autor z WP Super Cache, Donncha, napisał już wtyczkę o nazwie Cookies For Comments, która zasadniczo robi to samo, co właśnie napisałem.
Ponieważ jego wtyczka jest napisana o wiele bardziej elegancko niż moja wtyczka javascript, gorąco polecam jej pobranie.
Ale jeśli planujesz używać wtyczki Donncha’s Cookies For Comments, upewnij się, że dokonałeś następującej zmiany w swoim .htaccess, która różni się od instrukcji instalacji wtyczki.
Domyślnie wtyczka Donncha zaleca wstawienie następujących wierszy do pliku .htaccess. (Note: Zamiast tych wszystkich znaków i cyfr na końcu należy wstawić własną unikalną wartość pliku cookie, jak określono w dokumentacji plików cookie do komentarzy.)
Warunek przepisania %{HTTP_COOKIE} !^.*2071a9e39879b6a958b06162384d3c06.*$
RewriteRule ^wp-comments-post.php – [F,L]
Co robią te 2 linie robią? Zasadniczo te wiersze kodu wykrywają obecność tajnego pliku cookie, który został umieszczony na komputerze użytkownika. Jeśli plik cookie nie jest obecny, użytkownik lub robot spamujący jest kierowany na stronę WordPress 404 lub „nie znaleziono strony”.
Teraz problem z tą domyślną konfiguracją polega na tym, że WordPress wciąż jest wywoływany w celu przetworzenia strony 404, która nadal wymaga dużo zasobów serwera.
Lepszym rozwiązaniem byłoby użycie następującego kodu, w którym „error.html” to statyczna strona błędu w Twojej witrynie.
Warunek przepisania %{HTTP_COOKIE} !^.*2071a9e39879b6a958b06162384d3c06.*$
RewriteRule ^wp-comments-post.php error.html [L]
Różnica polega na tym, że bot spamowy jest kierowany do całkowicie statycznej strony błędu, która całkowicie uniemożliwia załadowanie WordPressa.
Problem rozwiązany??? Nie do końca
Tak więc zmiany, które opisałem powyżej, naprawiły mój problem ze spamem w komentarzach, ale po kilku dniach płynnego działania mój serwer znów zaczął się zawieszać! Przeglądając dzienniki mojego serwera, odkryłem następujące rzeczy.
mywifequitherjob.com GET /oxvumirserver33.rar
mywifequitherjob.com GET /oxvumirserver33.rar
mywifequitherjob.com GET /oxvumirserver33.rar
Zasadniczo jakaś nieuczciwa maszyna próbowała w kółko uzyskać dostęp do tego samego nieistniejącego pliku na moim serwerze, co powodowało awarię witryny. Teraz, w przypadku normalnych stron internetowych, te nieuczciwe dostępy w ogóle nie wpłynęłyby na serwer.
Jednak WordPress przetwarza wszystkie dostępy do nieistniejących plików i odsyła użytkowników do niestandardowej strony internetowej WordPress 404 lub „nie znaleziono strony”.
Czy wspominałem, że WordPress to świnia zasobów? Wystarczy kilka tych fałszywych dostępów, a Twój serwer nadal będzie się wyłączał, bez względu na to, jakiej wtyczki do buforowania używasz.
Sekret rozwiązania tego problemu jest podobny do mojego problemu ze spamem w komentarzach. W idealnej sytuacji chcemy całkowicie wyeliminować WordPressa z równania i wysłać nieuczciwego użytkownika na całkowicie statyczną stronę błędu, aby zaoszczędzić zasoby serwera.
Więc rozwiązaniem, które wymyśliłem, było dodanie następujących wierszy do mojego pliku .htaccess.
Warunek przepisania %{NAZWA_PLIKU_WNIOSKU} !-f
Warunek przepisania %{NAZWA_PLIKU_WNIOSKU} !-d
RewriteCond %{REQUEST_URI} !(robots\.txt|sitemap\.xml(\.gz)?)
RewriteCond %{NAZWA_PLIKU_WYMAGANIA} \.(css|js|html|htm|rtf|rtx|svg|svgz|txt|xsd|xsl|xml|asf|
asx|wosk|wmv|wmx|avi|bmp|klasa|divx|doc|docx|exe|gif|gz|gzip|ico|jpg|jpeg
|jpe|mdb|mid|midi|mov|qt|mp3|m4a|mp4|m4v|mpeg|mpg|mpe|mpp|odb|odc|odf|odg|
odp|ods|odt|ogg|pdf|png|pot|pps|pt|pptx|ra|ram|rar|swf|tar|tif|tiff|wav|wma
|wri|xla|xls|xlsx|xlt|xlw|zip)$ [NC]
Przepisz regułę .* – [L]
ErrorDocument 404 https://mywifequitherjob.com/404.html
Co robi cały ten kod? Zasadniczo, gdy żądany jest plik z mojego serwera, który pasuje do jednego z powyższych typów, chcę, aby mój serwer całkowicie ominął WordPress. Jeśli plik nie istnieje, użytkownik zostanie przekierowany na statyczną stronę błędu o nazwie 404.html.
Po raz kolejny ominięcie WordPressa jest kluczem do rozwiązania moich problemów z awariami. Ponieważ nieuczciwy proces w moich dziennikach serwera uzyskuje dostęp do pliku .rar, przekierowuję teraz tego złośliwego użytkownika na moją stronę błędu, która praktycznie nie zabiera żadnych zasobów.
Czy to rozwiąże wszystkie moje problemy?
Więc biegałem z powyższym 2 zmiany już od kilku tygodni, a mój serwer działa jak mistrz bez spowolnień. Niestety, sposób, w jaki napisany jest WordPress, uniemożliwia zapobieganie awariom serwera przez wszystkie nieuczciwe próby dostępu.
Na przykład, gdy ktoś próbuje uzyskać dostęp do artykułu, którego nie ma na moim blogu, WordPress nadal się ładuje. Więc teoretycznie, gdyby ktoś chciał usunąć MyWifeQuitHerJob.com lub jakikolwiek blog WordPress, wszystko, co musiałby zrobić, to uzyskiwać ciągły dostęp do nieistniejących stron w witrynie.
Ale w międzyczasie wszystko wydaje się być stabilne po mojej stronie. Mamy nadzieję, że w przyszłości WordPress będzie można załatać, aby rozwiązać te problemy z serwerem.
Gotowy, aby poważnie podejść do rozpoczęcia działalności online?
Jeśli naprawdę zastanawiasz się nad założeniem własnego biznesu online, musisz sprawdzić mój bezpłatny mini kurs Jak stworzyć niszowy sklep internetowy w 5 Łatwe kroki.
W tym 6 dzienny mini kurs, ujawniam kroki, które podjęliśmy z żoną, aby zarobić 100 tysięcy dolarów w ciągu zaledwie roku. Co najlepsze, jest to bezpłatne i będziesz otrzymywać cotygodniowe wskazówki i strategie e-commerce!
Powiązane posty w blogowaniu
O Stevenie Chou
Steve Chou jest wysoce rozpoznawalnym influencerem w przestrzeni e-commerce i nauczał tysiące studentów jak skutecznie sprzedawać fizyczne produkty online pod adresem ProfitableOnlineStore.com.
jego blogu, MyWifeRzućPracę.comzostał przedstawiony w Forbes, Inc, The New York Times, Entrepreneur i MSNBC.
On też jest współautor dla BigCommerce, Klaviyo, ManyChat, Printful, Privy, CXL, Ecommerce Fuel, GlockApps, Privy, Social Media Examiner, Web Designer Depot, Sumo i inne wiodące publikacje biznesowe.
Ponadto prowadzi popularny podcast e-commerceMoja żona rzuciła pracę, czyli 25 najlepszych programów marketingowych ze wszystkich Apple Podcasty.
Aby być na bieżąco ze wszystkimi najnowszymi trendami e-commerce, Steve prowadzi 7 sklep internetowy z figurkamiBumblebeeLinens.com, z żoną i zakłada doroczna konferencja e-commerce zwany Zjazd Sprzedawców.
Steve posiada tytuł licencjata i magistra elektrotechniki Uniwersytet Stanford. Pomimo tego, że studiował elektrotechnikę, znaczną część studiów podyplomowych spędził na studiowaniu przedsiębiorczości i mechaniki prowadzenia małych firm.
