Отключить обновление до Windows 10

Дата: 21.09.2015Метки:

Новость о бесплатном обновлении до Windows 10 стала для многих из нас приятной неожиданностью. Чтобы пользователи как можно скорее переходили на новую версию операционной системы, Microsoft даже добавила специальное напоминание о бесплатном обновлении до Windows 10.

Проблема в том, что вне зависимости от выбранных настроек, на компьютере с Windows 7 и 8.1 автоматически загружаются файлы для обновления до Windows 10. Даже если удалить файлы, то через некоторое время они снова буду загружены. Подобное поведение наблюдается на компьютерах с установленным пакетом обновлений KB3080351.

Поэтому, если вы по какой-либо причине решили отказаться от обновления до Windows 10, рекомендуется предварительно отключить его автоматическую загрузку. В противном случае, через Windows Update будет загружено от 4 до 6Гб информации.

Что бы отключить предложение о бесплатном обновлении до Windows 10 и запретить Windows загружать файлы, необходимо выполнить одно из указанных действий ниже.

Отключить обновления до Windows 10 с помощью утилиты GWX Stopper

Скачиваем утилиту GWX Stopper по этой ссылке. Чтобы отключить обновление до Windows 10 жмем кнопку Disable 'Get Windows 10' App.

Отключить обновления до Windows 10 в групповых политиках

Нажмите сочетание клавиш «Win + R», а затем выполнить команду:

gpedit.msc

В зависимости от языка системы, откройте раздел:

"Конфигурация компьютера" - "Административные шаблоны" - "Компоненты Windows" - "Центр обновления Windows" - "Отключить обновление до последней версии Windows через Центр обновления Windows"
"Computer Configuration" - "Administrative Templates" - "Windows Components" - "Windows Update" - "Turn off the upgrade to the latest version of Windows through Windows Update"

Что бы отключить обновление до Windows 10, включите политику «Enable» и сохраните изменения.

Отключить обновление до Windows 10 в реестре

Отключить обновление до Windows 10 можно в редакторе реестра. Нажмите сочетание клавиш «Win + R», а затем выполните команду:

regedit

В разделе:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Gwx

Необходимо создать параметр типа DWORD с именем DisableGwx и установить его значение равным 1.

Как вариант можно выполнить в командной строке или добавить bat-файл команду:

reg.exe add "HKLM\SOFTWARE\Policies\Microsoft\Windows\Gwx" /v DisableGwx /t REG_DWORD /d "1" /f

Если у вас отсутствуют пункты описанные в данной инструкции, необходимо установить обновление клиента Windows Update KB3065987 (Windows 7) или KB3065988 (Windows 8.1).

Установка Nginx с поддержкой PageSpeed

Дата: 20.09.2015Метки:

Основная функция использования модуля ngx_pagespeed — автоматическая оптимизации сайта с целью увеличения отзывчивости и пропускной способности при отдаче контента. Среди основных функций поддерживаемых модулем ngx_pagespeed: оптимизация страницы и всех связанных с ней CSS, JavaScript файлов, объединение нескольких файлов в один, уменьшение разрешения и сжатие изображений, оптимизация использования заголовков Expires, Cache-Control и Last-Modified.

Использование модуля ngx_pagespeed не требует изменения содержимого сайта, все преобразования выполняются на лету. Для снижения нагрузки на сервер PageSpeed использует встроенный механизм кэширования.

По умолчанию модуль ngx_pagespeed не включен в состав официальной сборки Nginx. Для его использования необходимо собрать Nginx с поддержкой модуля ngx_pagespeed из исходников.

Вначале необходимо установить все необходимы для сборки пакеты:

apt-get install build-essential zlib1g-dev libpcre3 libpcre3-dev unzip

Скачиваем скачиваем и распаковываем файлы модуля PageSpeed:

cd /usr/src
wget https://github.com/pagespeed/ngx_pagespeed/archive/release-1.9.32.6-beta.zip
unzip release-1.9.32.6-beta.zip
cd ngx_pagespeed-release-1.9.32.6-beta
wget https://dl.google.com/dl/page-speed/psol/1.9.32.6.tar.gz
tar -xzvf 1.9.32.6.tar.gz

Добавим в файл /etc/apt/sources.list официальный репозиторий для mainline-ветки Nginx:

deb http://nginx.org/packages/mainline/debian/ codename nginx
deb-src http://nginx.org/packages/mainline/debian/ codename nginx

Скачиваем и устанавливаем PGP-ключ, после чего не забудьте обновить индекс пакетов apt:

cd /tmp/ && wget http://nginx.org/keys/nginx_signing.key && apt-key add nginx_signing.key
apt-get update

Устанавливаем пакет dpkg-dev и все необходимые для сборки Nginx зависимости:

apt-get install dpkg-dev
apt-get build-dep nginx

Скачиваем исходники Nginx:

cd /usr/src
apt-get source nginx

Перед началом сборки и компиляции необходимо внести изменения в конфигурационный файл:

nano /tmp/nginx-1.9.3/debian/rules

Необходимо добавить путь к исходникам ngx_pagespeed в содержимое секций override_dh_auto_build и configure_debug:

override_dh_auto_build:
        dh_auto_build
        mv objs/nginx objs/nginx.debug
        CFLAGS="" ./configure 
                --prefix=/etc/nginx 
                --sbin-path=/usr/sbin/nginx 
                --conf-path=/etc/nginx/nginx.conf 
                --error-log-path=/var/log/nginx/error.log 
                --http-log-path=/var/log/nginx/access.log 
                --pid-path=/var/run/nginx.pid 
                --lock-path=/var/run/nginx.lock 
                --http-client-body-temp-path=/var/cache/nginx/client_temp 
                --http-proxy-temp-path=/var/cache/nginx/proxy_temp 
                --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp 
                --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp 
                --http-scgi-temp-path=/var/cache/nginx/scgi_temp 
                --user=nginx 
                --group=nginx 
                --with-http_ssl_module 
                --with-threads 
                --with-file-aio 
                $(WITH_SPDY) 
                --with-cc-opt="$(CFLAGS)" 
                --with-ld-opt="$(LDFLAGS)" 
                --add-module=/usr/src/ngx_pagespeed-release-1.9.32.6-beta
        dh_auto_build

Переходим к компиляции и сборку deb-пакета Nginx:

cd /usr/src/nginx-1.9.4
dpkg-buildpackage -rfakeroot -uc -b

Если в процессе не было ошибок, то в рабочем каталоге мы увидим собранные deb-пакеты Nginx. Перенесем их на рабочий сервер и выполним установку командой:

dpkg -i nginx_1.9.4-1~jessie_i386.deb

На этом процесс установки Nginx с поддержкой модуля ngx_pagespeed. Для проверки работы модуля PageSpeed, необходимо открыть конфигурационный файл Nginx:

nano /etc/nginx/nginx.conf

В секцию http необходимо добавить настройки ниже:

http {
pagespeed On;
# Указываем расположение кэша
pagespeed FileCachePath "/var/cache/ngx_pagespeed/";
}

Проверяем конфигурацию и применяем настройки Nginx:

nginx -t && service nginx reload

В следующей записи я подробнее опишу процесс настройки модуля PageSpeed в Nginx.

Используем dd для теста скорости диска

Дата: 19.09.2015Метки:

Изначально программа dd предназначена для копирования и конвертации файлов в Linux. Но благодаря своей простоте и доступности, часто dd используют для тестирования скорости чтения/записи на диск.

И хотя это не самый точный метод для оценки I/O, тем не менее он достаточно эффективен в ситуациях, когда необходимо оценить производительность файловой системы в Linux. Данный способ подойдет для замеров скорости таких устройств как HDD, SSD и USB накопители.

Для того что бы результаты dd были более точными, необходимо предварительно очистить кэш:

echo 3 > /proc/sys/vm/drop_caches

В процессе выполнения, команда dd создаст файл /tmp/tempfile и запишет его нулями. Для более точных результатов, необходимо что бы данные были физически записаны на диск, для этого необходимо использовать параметр conv=fdatasync.

Команда dd для проверки скорости записи на диск:

# dd if=/dev/zero of=/tmp/tempfile bs=1M count=1024 conv=fdatasync,notrunc
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 2.7261 s, 394 MB/s

Команда dd для проверки скорости чтения с диска:

# dd if=/tmp/tempfile of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 1.90372 s, 564 MB/s

Для удаления файла, необходимо выполнить команду:

rm /tmp/tempfile

Настройка работы MySQL Query Cache

Дата: 18.09.2015Метки:

Использование кэширования запросов, является одним из ключевых факторов влияющих на производительность работы MySQL. Функционал Query Cache открывает дополнительные возможности для оптимизации базы данных и позволяет снизить время обработки запросов в несколько раз. Наилучшую эффективность работы Query Cache показывает на веб-серверах, у которых таблицы не обновляются слишком часто и присутствует много идентичных запросов.

Для подходящего запроса типа SELECT, MySQL автоматически сохраняет текст запроса и данные выборки в кэше. Все идентичные запросы в дальнейшем, будут обрабатываться в обход БД с помощью функции MySQL Query Cache. Таким образом, кэшированные запросы не выполняется вовсе.

Для работы Query Cache в значении переменной query_cache_type должно быть установлено ON или DEMAND, а query_cache_size быть отличной от нуля.

В противном случае, необходимо добавить соответствующие настройки в секцию [mysqld] конфигурационного файла MySQL:

nano /etc/mysql/my.cnf

[mysqld]
query_cache_type        = ON
query_cache_limit       = 1M
query_cache_size        = 16M

За настройку работы функции Query Cache отвечают системные переменные начинающиеся с 'query_cache_'.

mysql> SHOW VARIABLES LIKE 'query_cache_%';

+------------------------------+----------+
| Variable_name                | Value    |
+------------------------------+----------+
| query_cache_limit            | 1048576  |
| query_cache_min_res_unit     | 4096     |
| query_cache_size             | 16777216 |
| query_cache_type             | ON       |
| query_cache_wlock_invalidate | OFF      |
+------------------------------+----------+
5 rows in set (0.00 sec)

query_cache_limit — размер максимальной выборки, которая будет записана в кэш. В качестве значения необходимо указать максимальный размер самого тяжелого запроса, но не стоит чрезмерно завышать значение данного параметра.
query_cache_min_res_unit — минимальный размер выделяемого блока памяти для хранения результатов кэшированного запроса. Для записи данных в кэш MySQL разбивает выборку на отдельные блоки с минимальным размером query_cache_min_res_unit. Последний такой блок обрезается до размера данных, а оставшаяся память освобождается. Для записи данных в кэш, MySQL по мере необходимости выделяет блоки размером query_cache_min_res_unit. В качестве значения необходимо указать среднее значение размера выборки от всех запросов. Примерное значение query_cache_min_res_unit можно вычислить по формуле query_cache_min_res_unit = (query_cache_size – Qcache_free_memory) / Qcache_queries_in_cache. Слишком большое значение будет способствовать фрагментации кэша, слишком маленькое может стать причиной снижения производительности.
query_cache_size — размер памяти выделяемый для хранения кэша запросов. Значение равное 0 отключает работу MySQL Query Cache. Устанавливаем значение исходя из количества свободной оперативной памяти в системе. Для выбора оптимального значения, в идеале переменная Qcache_lowmem_prunes должна равняться нулю. В противном случае, рекомендуется чтобы в процессе работы MySQL это значение увеличивалось незначительно.
query_cache_type — параметр отвечающий за работу кэша. Может принимать значения: ON, DEMAND и OFF. Опция включает или отключает работу MySQL Query Cache, если значение query_cache_type установлено равным DEMAND, MySQL будет кэшировать только запросы с директивой SQL_CACHE.
query_cache_wlock_invalidate — определяет будут ли данные браться из кэша, если таблица, к которым они относятся заблокирована на чтение. Если значение параметра query_cache_wlock_invalidate принимает значение OFF, то будет доступно получение данных заблокированной таблицы из Query Cache.

Для мониторинга MySQL Query Cache используется команда:

mysql> SHOW GLOBAL STATUS LIKE 'Qcache%';

+-------------------------+----------+
| Variable_name           | Value    |
+-------------------------+----------+
| Qcache_free_blocks      | 158      |
| Qcache_free_memory      | 16420704 |
| Qcache_hits             | 143791   |
| Qcache_inserts          | 21851    |
| Qcache_lowmem_prunes    | 0        |
| Qcache_not_cached       | 12506    |
| Qcache_queries_in_cache | 215      |
| Qcache_total_blocks     | 598      |
+-------------------------+----------+
8 rows in set (0.00 sec)

Qcache_free_blocks — количество свободных блоков в кэше. Чем больше незадействованных блоков, тем больше степень фрагментации кэша. Если результат большинства запросов имеет небольшой объем данных выборки, необходимо уменьшить значение параметра query_cache_min_res_unit.
Qcache_total_blocks — количество занятых блоков.
Qcache_free_memory — объем свободной памяти, отведенной под кэш.
Qcache_hits — количество запросов отработанных из кэша.
Qcache_inserts — количество запросов записанных в кэш.
Qcache_lowmem_prunes — количество запросов, которые были удалены из-за переполнения кэша.
Qcache_not_cached — количество запросов не подлежащих кэшированию.
Qcache_queries_in_cache — количество запросов находящихся в кэше.

Кратко механизм работы Query Cache выглядит следующим образом. Под кэширование запросов MySQL выделяет в памяти область размером query_cache_size. Для записи результатов запроса сервер создает в кэше свободный блок размером query_cache_min_res_unit. После заполнения блока, сервер создает новый пустой блок и так до тех пор, пока все данные выборки не будут записаны в кэш. После чего свободная область памяти последнего блока выделяется в новый свободный блок. В случае если размер выборки превышает установленное значение query_cache_limit, то запись прекращается, а занятое память освобождается.

Фрагментация кэша возникает при удалении выборки из кэша, когда для записи результатов новых запросов количества освободившихся блоков недостаточно. Для того что бы определить степень фрагментации, необходимо обратить внимание на значение переменной Qcache_free_blocks. В идеале значение должно быть равно единице, в случае фрагментации — Qcache_total_blocks / 2. Так же можно определить, что ваш кэш запросов сильно фрагментируется, если значение Qcache_lowmem_prunes постоянно возрастает при том, что значение Qcache_free_memory далеко от нуля.

Для дефрагментации кэша используется команда:

mysql> FLUSH QUERY CACHE;

Для оценки эффективности работы кэша используется формула Qcache_hits / (Qcache_hits + Com_select).

Определяем MIME-типы для файлов сайта

Дата: 17.09.2015Метки:

При настройке веб-сервера или прокси, часто возникает необходимость указать список MIME-типов используемых на конкретном сайте. С данным вопросом я часто сталкиваюсь в процессе настройки GZIP на Nginx, когда необходимо указать список MIME-типов для файлов, которые будут передаваться клиенту в сжатом виде. Также список MIME-типов может потребоваться при настройке различных фильтров в SQUID.

Для определения MIME-типов можно воспользоваться соответствующей таблицей, но для этого необходимо предварительно знать список всех загружаемых браузером файлов. Поэтому, для этих целей я предпочитаю использовать функционал инструмента HttpWatch — сниффер используемый для отладки и мониторинга работы сайтов.

После установки HttpWatch автоматически интегрируется с браузерами Internet Explorer и Firefox. После чего с помощью HttpWatch можно просмотреть весь HTTP и HTTPS трафик генерируемый во время доступа к веб-странице. Для запуска инструмента необходимо Firefox, после чего выбрать «HttpWatch» в контекстном меню браузера. Затем необходимо нажать кнопку «Record» и открыть адрес анализируемой страницы. Для просмотра MIME-типа для каждого из загруженных сайтов, необходимо навести курсор на иконку расположенную в столбце «Type».

Отключить запуск agetty в Debian

Дата: 16.09.2015Метки:

Для управления доступом к физическим и виртуальным терминалам tty, Debian использует процессы agetty. По умолчанию после загрузки в системе запущено 6 виртуальных терминалов. Для того что отключить не используемые процессы agetty, необходимо в файле getty-static.service изменить параметры запуска службы:

nano /lib/systemd/system/getty-static.service

Для того что бы уменьшить количество запущенных виртуальных терминалов, необходимо удалить из секции [Service] неиспользуемые tty:

[Service]
Type=oneshot
ExecStart=/bin/systemctl --no-block start getty@tty2.service
RemainAfterExit=true

Настройка Nginx fastcgi_cache для WordPress

Как показывает опыт, только лишь с помощью утилиты ApacheBench можно положить WordPress на среднестатистическом VPS. Проблема заключается том, что в большинстве случаев PHP является узким местом в работе веб-сервера. Использование OPCache позволяет значительно ускорить работу PHP скриптов, но это не изменить ситуацию, когда при высокой посещаемости скрипты будут создавать серьезную нагрузку на CPU.

Связи с чем, на высоконагруженных сайтах приходится использовать кеш в CDN или устанавливать дополнительные плагины для кэширования страниц в WordPress. Я предлагаю более практичный и удобный вариант — использовать внутреннее кэширование Nginx fastcgi_cache. После чего производительность веб-сервера возрастает в десятки раз.

Главный недостаток использования fastcgi_cache — отсутствие встроенного механизма для удаления из кэша потерявших свою актуальность страниц. Зато данная проблема легко решается за счет использования специального плагина для WordPress, который при наличии изменений на сайте будет давать команду Nginx очищать кэш.

Для начала необходимо убедится, что на сервере установлен Nginx с поддержкой fastcgi_cache_purge. Для этого нужно выполнить следующую команду:

nginx -V 2>&1 | grep nginx-cache-purge -o

В результате выполнения команды вы должны увидеть следующее:

nginx-cache-purge

В противном случае необходимо установить Nginx c поддержкой с поддержкой модуля fastcgi_cache_purge. В зависимости от потребностей вашего сайта, можно вообще отказаться от данной функции. Для этого необходимо убрать из конфигурационного файла Nginx секцию location ~ /purge(/.*).

Для того чтобы дать сигнал Nginx какая страница была изменена, мы будем использовать WordPress плагин Nginx Helper. После каждого обновления записи он автоматически даст команду Nginx удалить страницу из кэша. После активации плагина в настройках необходимо включить опцию «Enable Cache Purge» и задать соответствующие правила.

Если на вашем сервере достаточно свободной памяти, то я рекомендую использовать ramdisk для хранения содержимого fastcgi_cache. На серверах с Debian или Ubuntu кэша рекомендуется использовать смонтированный как tmpfs в RAM каталог /var/run. При этом следует учитывать, что по умолчанию для него зарезервировано 20% от используемой в системе RAM.

Для проверки свободного места необходимо выполнить команду:

df -h /var/run

Результат выполнения команды:

Filesystem      Size  Used Avail Use% Mounted on
tmpfs           2.1G  316K  2.1G   1% /run

В моем случае, для использования fastcgi_cache можно выделить до 2Гб памяти.

Обычно под fastcgi_cache я выделяю 100Мб памяти, время жизни страниц в кэше устанавливаю равным 60 минутам. обычно эти настройки подбираются опытным путем на основе конкретного сайта и характеристик сервера. Для использования fastcgi_cache в Nginx необходимо добавить в конфигурационный файл /etc/nginx/nginx.conf следующие настройки:

fastcgi_cache_path /var/run/nginx-cache levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
fastcgi_cache_use_stale error timeout invalid_header http_500;
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;

Отдельно следует уделить внимание опции fastcgi_cache_use_stale, она указывает веб-серверу что если PHP перестанет отвечать, Nginx должен отдать страницу из кэша.

Секция server описывающая настройки сайта, должна выглядеть следующим образом:

server {
	server_name example.com www.example.com;

	root /usr/local/nginx/html;
	index index.php index.html;

	set $skip_cache 0;

	# Отключаем кэш для POST-запросов
	if ($request_method = POST) {
		set $skip_cache 1;
	}   
	if ($query_string != "") {
		set $skip_cache 1;
	}   

	# Не кэшировать страницы админки, rss и sitemap
	if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php|sitemap(_index)?.xml") {
		set $skip_cache 1;
	}   

	# Отключить кэш для пользователей прошедших авторизацию или оставивших комментарий
	if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
		set $skip_cache 1;
	}

	location / {
		try_files $uri $uri/ /index.php?$args;
	}    

	location ~ .php$ {
		try_files $uri = 404;
		fastcgi_pass unix:/var/run/php-fpm.sock;
		fastcgi_index index.php;
		fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
		include fastcgi_params;

		fastcgi_cache_bypass $skip_cache;
	        fastcgi_no_cache $skip_cache;
		fastcgi_cache WORDPRESS;
		fastcgi_cache_valid 60m;
	}

	location ~ /purge(/.*) {
	    fastcgi_cache_purge WORDPRESS "$scheme$request_method$host$1";
	}	

}

После изменений, необходимо проверить конфигурацию и применить настройки Nginx.

nginx -t
service nginx reload

Для проверки работы кэширования необходимо открыть Chrome в режиме инкогнито, открытые в браузеры страницы должны попасть в кэш Nginx. Для проверки содержимого fastcgi_cache используем команду:

ls -la /var/run/nginx-cache

Закрываем доступ к админке WordPress

Если у вас до сих пор свободно открыт доступ к админке WordPress, во избежание лишних проблем, я советую закрыть эту потенциальную дыру в безопасности. Возможно вы считаете, что для WordPress надежного пароля будет вполне достаточно. Но поверьте, закрыв доступ к админке WordPress вы не только снизите вероятность взлома, но и устраните одну из лазеек через которую могут положить ваш сайт.

Один из самых распространенных методов защиты админки сайта — использование HTTP-авторизации на уровне веб-сервера. Для этого нам необходимо предварительно сгенерировать файл .htpasswd, в котором будут хранится данные для авторизации. Затем указываем путь к .htpasswd в конфигурационном файле Nginx. Теперь при переходе по адресу /wp-admin или /wp-login.php Nginx запросит данные для авторизации.

Для генерации пароля необходимо использовать утилита генерации паролей .htpasswd. Пример конфигурации Nginx:

server {
    listen       80;
    server_name  localhost;

    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }

    location ~ ^/(wp-admin|wp-login.php) {
        auth_basic "closed site";
        auth_basic_user_file conf/.htpasswd;
        location ~ .php$ {
            root           html;
            fastcgi_pass   127.0.0.1:9000;
            fastcgi_index  index.php;
            fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
            include        fastcgi_params;
        }
    }
    
    location ~ .php$ {
        root           html;
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
        include        fastcgi_params;
    }
}

Для удобства можно вынести секцию location ~ .php$ в отдельный файл:

# nano /etc/nginx/php-fpm.conf

location ~ .php$ {
    root           html;
    fastcgi_pass   127.0.0.1:9000;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
    include        fastcgi_params;
}

Тогда конфигурация Nginx будет выглядеть следующим образом:

server {
    listen       80;
    server_name  localhost;

    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }

    location ~ ^/(wp-admin|wp-login.php) {
        auth_basic "closed site";
        auth_basic_user_file conf/.htpasswd;

        include php-fpm.conf;
    }
    
    include php-fpm.conf;
}

Как по мне, метод описанный выше не самый удобным вариант для защиты WordPress. Поэтому, вместо HTTP-авторизации по паролю, я предпочитаю ограничить доступ к админке WordPress используя фильтр на основе ip-адреса. Данный способ не совсем правильно использовать если ваш провайдер использует динамическую адресацию, но как вариант придется указать диапазон адресов подсети провайдера.

server {
    listen       80;
    server_name  localhost;

    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }

    location ~ ^/(wp-admin|wp-login.php) {
        allow 82.82.82.82;    // Указываем адрес вашего подключения
        allow 82.82.82.0/24;  // Или подсети вашего провайдера (ip-calculator.ru)
        deny all;

        include php-fpm.conf;
    }
    
    include php-fpm.conf;
}

Удалить сайт из Internet Archive

В большинстве случаев использование сервиса Wayback Machine от archive.org не имеет никакого практического смысла. В случае потери данных, теоретически возможно восстановить данные из Wayback Machine, но данный способ крайне не удобен и не дает никакой гарантии сохранности абсолютно всех данных. Кроме того, зачастую функциями данного сервиса злоупотребляют. Контент восстановленный из архива, в последствии используют для создания фейковых сайтов на перехваченных вовремя не продленных доменах.

Поэтому, для всех своих сайтов я предпочитаю закрыть доступ для робота Internet Archive. Для этого необходимо добавить в robots.txt следующие строки:

User-agent: ia_archiver
Disallow: /

Это не только запретить Internet Archive сканировать ваш сайт, но и даст сигнал на удаления всех сохраненных ранее страниц из Wayback Machine.

Исключить себя из статистики Яндекс.Метрики

При установке Яндекс.Метрики на новые и еще не раскрученные сайты, из-за низкой посещаемости собственные визиты на сайт сильно искажают реальную статистику посещений. Для того что бы иметь точные данные, нам необходимо исключить себя из общей статистики посещений.

Для этих целей в Яндекс.Метрике есть специальные фильтры, позволяющие не учитывать посетителей по указанному ip или диапазону адресов. Для того что бы добавить новый фильтр необходимо зайти в панель управления сайтом, после чего переходим в меню Настройки — Фильтр. После чего необходимо выбрать опцию «Не учитывать мои визиты» и добавить соответствующие параметры фильтрации.

Как вариант, можно сделать собственный фильтр адресов на стороне сервера. Данный метод хорошо подойдет как для Яндекс.Метрики так и для других сервисов оценки посещаемости сайтов. Для этого необходимо добавлять код счетчика в тело HTML документа только для тех посетителей, ip которых не попадает под заданный нами фильтр адресов. Для этого необходимо добавить в PHP шаблон страницы следующий код:

<?php if ( $_SERVER["REMOTE_ADDR"] != '127.0.0.1' ): ?>
// Код счетчика
<?php endif; ?>