Установка proxy-сервера в ubuntu

P.S. SOCKS-прокси

SOCKS-прокси имеют несколько версий протокола (SOCKSv4/SOCKSv4.5/SOCKSv5) и ряд особенностей. Подробнее описано тут — https://3proxy.ru/howtor.asp

Например SOCKSv4 не поддерживает IPv6 на уровне протокола, в SOCKSv5 есть поддержка IPv6 с помощью отдельного вида запроса, который должен быть реализован в клиентском приложении или соксификаторе. Авторизации по паролю поддерживаются в SOCKS так же как и через HTTP-прокси. SOCKSv5 имеет поддержку UDP.

В шаге-4 в конфиге /etc/3proxy/3proxy.cfg
вместо последней строчки можно одновременную работы с HTTP-прокси настроить — тогда просто добавить в конец строку:

socks -p1080

Параметр (-p1080) это номер порта. Можно другой указать, но этот стандартный.

В шаге-6 при использовании Uncomplicated Firewall (UFW):

sudo ufw allow 1080
sudo ufw enable

При использовании iptables:

sudo iptables -I INPUT -p tcp -m tcp --dport 1080 -j ACCEPT
sudo iptables -I INPUT -p udp -m udp --dport 1080 -j ACCEPT

Настройка Let’s Encrypt

Для настройки Let’s Encrypt (далее LE) необходимо установить программное обеспечение CertBot:

sudo apt update
sudo apt install -y certbot

Обратите внимание, ваш сервер должен быть доступен по доменному имени извне перед началом запуска команды получения сертификата. Не забывайте везде заменять домен ngx.cs2.netpoint-dc.com на ваш домен

sudo certbot certonly --standalone -m user@site.com --agree-tos -d ngx.cs2.netpoint-dc.com

После успешного завершения работы приложения вы получите сообщения следующего вида:

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/ngx.cs2.netpoint-dc.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/ngx.cs2.netpoint-dc.com/privkey.pem
   Your cert will expire on 2019-06-27. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

В данном сообщении содержится важная информация о месте хранения данных сертификата. Мы будем использовать это в дальнейшем.

Следующий шаг — настроить автопродление сертификата. Сертификаты LE требуется продлевать каждые 90 дней. Мы просто настроим ежедневную задачу CRON, которая будет это делать. Для этого создайте файл /etc/cron.daily/le-renew со следующим содержимым:

#/bin/bash
certbot renew

Пометьте его как исполняемый и проверьте, что он работает:

sudo chmod 755 /etc/cron.daily/le-renew
sudo /etc/cron.daily/le-renew

Конфигурационный файл

Финальный вариант файла

# Общие настройки
daemon
pidfile /opt/3proxy/3proxy.pid
timeouts 1 5 30 60 180 1800 15 60

setgid 994
setuid 996

# DNS серверы и размер кэша
nserver 77.88.8.8
nserver 8.8.8.8
nserver 2a02:6b8::feed:0ff
nserver 2001:4860:4860::8888
nscache 65536

# Внешний интерфейс
external 185.53.170.60

# Можно разрешить глобально. В нашем примере для HTTP-прокси будут открыты только 80 и 443. Для socks-прокси 80, 443 и другие.
# allow * * * 80-88,8080-8088 HTTP
# allow * * * 443,8443 HTTPS
users rootwelt:CL:CoolPassword1337

# Лог файл
log /opt/3proxy/log/3proxy.log D
rotate 7
logformat "L%d-%m-%Y %H:%M:%S %z %N.%p %E %U %C:%c %R:%r %O %I %h %T"
# log /dev/null для отключения логов

# HTTP proxy
auth strong
flush
allow  * * * 80,443
proxy -n -a -p3333

# Socks5
auth strong
flush
allow * * * 80-88,8080-8088 HTTP
allow * * * 443,8443 HTTPS
allow * * * 1500,2087,2222
socks -n -a -p4444

# Статистика для пользователей. Вряд ли это нужно в контексте socks-сервера для обхода блокировок.
# flush
# auth iponly
# allow *
# admin -p8889 -s

# Админ интерфейс. Да, есть такая фича, но лучше не включать.
# flush
# auth strong
# allow Ubermensch 10.20.30.40
# deny *
# admin -p8888

end

Небольшие пояснения по опциям flush и allow

Из FAQ: Команда flush используется для сброса существующего списка доступа (это необходимо для того, чтобы можно было задать различные списки доступа для различных служб).

Мы можем например глобально разрешить только HTTP и HTTPS, но отдельно для socks открыть дополнительный доступ для TCP 1500.

Allow, как нетрудно догадаться служит для разрешения соединения. Синтаксис следующий:

allow <userlist> <sourcelist> <targetlist> <targetportlist> <commandlist> <weekdays> <timeperiodslist>

То есть в нашем тестовом конфигурационном файле разрешено

• доступ всем пользователям (список логинов)
• доступ с любых адресов
• доступ к любым адресам
• доступ только к указанным портам

Пример ограничения использования прокси-сервера подсетями Telegram (источник)

allow * * 91.108.4.0/22,91.108.8.0/22,91.108.56.0/22,149.154.160.0/20,149.154.164.0/22,91.108.16.0/22,91.108.56.0/23,149.154.168.0/22,91.108.12.0/22,149.154.172.0/22,91.108.20.0/22,91.108.36.0/23,91.108.38.0/23,109.239.140.0/24

Список подсетей Telegram — https://bgp.he.net/search?search%5Bsearch%5D=Telegram&commit=Search

Дополнительные настройки

Настройки, которые могут не понадобиться. Но они позволят настроить дополнительные возможности прокси-сервера.

Настройка портов и прокси-интерфейсов

При необходимости, можно настроить 3proxy на использование разных интерфейсов на разных портах:

vi /etc/3proxy/3proxy.cfg

proxy -n -a -p3128 -i192.168.0.23 -e222.222.222.222
proxy -n -a -p8080 -i192.168.1.23 -e111.111.111.111

*  3proxy будет слушать на порту 3128 с внутреннего интерфейса 192.168.0.23 и направлять пакеты в сеть Интернет через внешний интерфейс 222.222.222.222, а также, на порту 8080 для внутреннего и внешнего интерфейсов 192.168.1.23 и 111.111.111.111 соответственно.
* не забываем также настраивать брандмауэр (вначале инструкции мы открывали только 3128 порт).

systemctl restart 3proxy

Ограничение пропускной способности

При необходимости, можно ограничить скорость.

vi /etc/3proxy/3proxy.cfg

bandlimin 1000000 user1,user3
bandlimin 5000000 user2,user4

*  в данном примере пользователям user1 и user3 установлено ограничение в 1000000 бит/сек (1 мбит); для user2 и user4 — 5 мбит/сек.

systemctl restart 3proxy

Ограничения доступа

Можно ограничить доступ и разрешить только для определенных портов, сетей и пользователей.

vi /etc/3proxy/3proxy.cfg

Синтаксис:

allow <userlist> <sourcelist> <targetlist> <targetportlist> <commandlist> <weekdays> <timeperiodslist>
deny <userlist> <sourcelist> <targetlist> <targetportlist> <commandlist> <weekdays> <timeperiodslist>

* где:

• userlist — список пользователей через запятую.
• sourcelist — сети клиентов через запятую.
• targetlist — сети назначения через запятую.
• targetportlist — порты назначения через запятую.
• commandlist — команды, к которым применяется правило.
• weekdays — в какие дни недели работает правило. 0 — 6 — Пн — Вс, 7 — тоже Вс.
• timeperiodslist — время, когда работает правило. Указываются диапазоны.

Примеры:

allow * * * 80 HTTP
allow * * * 443,8443 HTTPS
allow * * * 21 FTP

*  в данном примере пользователям user1 и user3 установлено ограничение в 1000000 бит/сек (1 мбит); для user2 и user4 — 5 мбит/сек.

Также, ограничить доступ можно по количеству одновременных соединений для каждой службы:

maxconn 700
proxy -n -a -p3128 -i192.168.0.23 -e222.222.222.222
proxy -n -a -p8080 -i192.168.1.23 -e111.111.111.111

* таким образом, мы установим 700 максимальных соединений для прокси на порту 3128 и 700 — для proxy на порту 8080.

systemctl restart 3proxy

Configuring Your Browser to Use Proxy #

In this section well show you how to configure your browser to use Squid proxy.

Firefox

The steps below are the same for Windows, macOS, and Linux.

1. In the upper right-hand corner, click on the hamburger icon to open Firefox’s menu:

2. Click on the link.

3. Scroll down to the section and click on the button.

4. A new window will open.

   • Select the radio button.
   • Enter your Squid server IP address in the field and in the field.
   • Select the checkbox.
   • Click on the button to save the settings.

At this point, your Firefox is configured and you can browse the Internet through the Squid proxy. To verify it, open , type “what is my ip” and you should see your Squid server IP address.

To revert back to the default settings go to , select the radio button and save the settings.

There are also several plugins that can help you to configure Firefox’s proxy settings such as FoxyProxy .

Google Chrome

Google Chrome uses the default system proxy settings. Instead of changing your operating system proxy settings you can either use an addon such as SwitchyOmega or start Chrome web browser from the command line.

To launch Chrome using a new profile and connect to the Squid server, use the following command:

Linux :

macOS :

Windows :

The profile will be created automatically if it does not exist. This way you can run multiple instances of Chrome at the same time.

To confirm the proxy server is working properly, open , and type “what is my ip”. The IP shown in your browser should be the IP address of your server.

Шаг 3 – Изменение конфигурации по умолчанию. Включение обратного прокси-сервера

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

В этом руководстве мы применяем настройки на уровне виртуального хоста. При установке по умолчанию Apache, есть только один включен, виртуальный хост по умолчанию. Тем не менее, вы можете использовать все эти фрагменты конфигурации в других виртуальных хостах.

Если ваш сервер работает на Apache как HTTP и HTTPS – сервер, ваша обратная конфигурация прокси – сервера должна быть размещена как в HTTP и HTTPS виртуальных хостах.

Откройте файл по умолчанию Apache конфигурации, используя nano или ваш любимый текстовый редактор.

Внутри этого файла вы найдете блок , начиная с первой строки. В первом примере ниже показано, как настроить этот блок для обратного прокси – сервера для одного сервера бэкэнда, а второй устанавливает балансировкой нагрузки обратного прокси для нескольких внутренних серверов.

Пример 1 – Обратное проксирование сервера

Заменить все содержимое внутри блока VirtualHost со следующим, ваш файл конфигурации должен выглядит следующим образом:

Если вы следовали вместе с серверами например, на шаге 2, используйте 127.0.0.1:8080 как написано в блоке выше. Если у вас есть свои собственные серверы приложений, использовать их адреса.

• ProxyPreserveHost делает Apache передают оригинальный Host заголовок на внутренний сервер. Это полезно, так как это делает сервер бэкенд осознаный адрес, используемый для доступа к приложению.
• ProxyPass главная директива конфигурации прокси. В этом случае, он указывает, что все в корневом URL ( / ) должен быть отображен на внутренний сервер по указанному адресу. Например, если Apache получает запрос на /example , он будет подключаться и вернет ответ на оригинальный клиент. http:// your_backend_server /example
• ProxyPassReverse должен иметь ту же конфигурацию, что и ProxyPass . Это говорит Apache, чтобы изменить заголовки ответа от сервера бэкэнда. Это гарантирует, что если внутренний сервер возвращает заголовок перенаправления местоположения, браузер клиента будет перенаправлен на адрес прокси – сервера и не адреса сервера, бэкенда, который не будет работать, как предполагалось.

Чтобы изменения вступили в силу, перезапустите Apache.

Теперь, если вы получаете доступ к http://your_server_ip через веб – браузер, вы увидите ответ сервера бэкэнда вместо стандартной страницы приветствия Apache. Если вы следовали инструкциям Шаг 2, то вы будете видеть Привет мир!

Пример 2 – балансировки нагрузки между несколькими серверами Backend

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

Замените все содержимое внутри блока VirtualHost следующим, так что ваш файл конфигурации выглядит следующим образом:

Конфигурация аналогична предыдущей, но вместо указания одного сервера бэкэнд напрямую, мы использовали дополнительный блок Proxy для определения нескольких серверов. Блок с именем balancer:// mycluster (имя может быть свободно изменено) и состоит из одного или нескольких BalancerMember , которые определяют, лежащие в основе адреса бэкенда сервера. ProxyPass и директива ProxyPassReverse используют пул балансировки нагрузки с именем mycluster вместо конкретного сервера.

Если вы следовали примеру на шаге 2, используя 127.0.0.1:8080 и 127.0.0.1:8081 для директивы BalancerMember , как написано в блоке выше. Если у вас есть свои собственные серверы приложений, используйте их адреса вместо этих.

Чтобы изменения вступили в силу, перезапустите Apache.

Зайдите в веб – браузере по адресу http://your_server_ip, вы увидите бэкэнд сервера вместо стандартной страницы Apache. Если вы следовали инструкциям на Шаге 2, обновите страницу несколько раз должен показать Привет, мир! и AndreyEx мир!, То есть обратный прокси – сервер работал и балансировка нагрузки между обоими серверами.

1. Squid

Squid — это лучший прокси серевер для Linux с поддержкой таких протоколов, как: HTTP, HTTPS, FTP и многих других. Он позволяет повысить пропускную способность сети и сократить время отклика сайтов путем кэширования ресурсов и страниц. Страницы и файлы, которые запрашиваются часто могут быть использованы повторно. Вы можете настроить кэширование как в оперативную память, так и на жесткий диск, если нужно кэшировать много данных при медленном интернете.

Кроме того, в Squid есть очень широкие возможности контроля доступа к сетевым ресурсам. Вы можете блокировать не только банальные запросы к доменам или загрузку файлов определенных форматов, но и доступ к сети в определенное время, работу протоколов и портов, а также многое другое. Squid поддерживает не только операционную систему Linux, но и Windows. Изначально программа могла работать только в Linux, но затем была портирована и для Windows. Мы уже рассматривали настройку Squid в Ubuntu в одной из предыдущих статей.

Установка Nginx

В этой части урока мы установим Nginx и настроим его для балансировки трафика между двумя upstream-серверами, запущенными ранее с поддержкой сертификата LE. Установка из пакетов выполняется стандартным способом:

sudo apt update
sudo apt install -y nginx

Теперь настроим конфигурацию для сайта, создав новый файл настроек для виртуального хоста — /etc/nginx/sites-available/ngx.cs2.netpoint-dc.com. Добавим в него следующее содержимое:

# переадресация с HTTP на HTTPS
#
server {
    if ($host = ngx.cs2.netpoint-dc.com) {
        return 301 https://$host$request_uri;
    }
    
    listen 80;
    listen :80;
    server_name ngx.cs2.netpoint-dc.com;
}

# upstream-серверы для балансировки (python)
#
upstream dirlist {
        ip_hash; # липкая балансировка по IP-клиента
        server 127.0.0.1:8081;
        server 127.0.0.1:8082;
}

# обработка SSL и соединение с upstream-серверами
#
server {
  listen 443 ssl;
  listen :443 ssl;
  server_name ngx.cs2.netpoint-dc.com;
  ssl_certificate /etc/letsencrypt/live/ngx.cs2.netpoint-dc.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/ngx.cs2.netpoint-dc.com/privkey.pem;
  access_log /var/log/nginx/website_access.log;
  error_log /var/log/nginx/website_error.log;
 
  # все запросы отправляем на upstream
  location / {
    proxy_pass http://dirlist/;
  }
}

Теперь активируем созданный виртуальный хост:

sudo ln -s /etc/nginx/sites-{available,enabled}/ngx.cs2.netpoint-dc.com
sudo nginx -t && sudo service nginx restart

Теперь при заходе через браузер на https://ngx.cs2.netpoint-dc.com/ вы будете видеть содержимое каталога, который отдается одним из upstream-серверов. В нашей настройке мы использовали ключевой слово ip_hash, что говорит Nginx делать липкую баансировку. Это означает, что до тех пор пока upstream-сервер, на который были распределены запросы от вашего IP работает, вы будете обслуживаться на нем.

Nginx поддерживает и другие способы, кроме ip_hash, например, least_conn, при этом Nginx будет выбирать наименее загруженный upstream-сервер.

Compiling from source code

Compiling from source code more preffer, becouse you will get latest version and instruction is same for all unix versions and distributives, for example installation from repository is not supported for latest Ubuntu versions

For compiling 3proxy form source code you need to install git, make and gcc

Type into your terminal

apt-get install gcc make git -y

Next, browse to home dir

cd ~
git clone https://github.com/z3APA3A/3proxy.git

this will download latest version of 3proxy to your machine

next step to compile it and setup

cd 3proxy
make -f Makefile.Linux

Next step to put files into correct path and setup autostart of service

mkdir /usr/local/etc/3proxy/bin –p
cp src/3proxy /usr/local/etc/3proxy/bin
cp ./scripts/rc.d/proxy.sh /etc/init.d/3proxy

For CentOS

chkconfig 3proxy on

For Debian

update-rc.d 3proxy defaults

Now you need to create config file

touch /usr/local/etc/3proxy/3proxy.cfg

3proxy — компактный, зараза, но мощный. Установка и настройка 3proxy

Захотелось мне тут с работы получить доступ к своим двум локальным сетям, доступным из дома. Простой и легковесный прокси-сервер с авторизацией — неплохое решение, на мой взгляд. 3proxy многоплатформенный компактный прокси-сервер, просто находка, ну не ставить же для таких простых задач SQUID, в самом деле. Вот об установке и настройке 3proxy на домашнем сервере мы и поговорим сегодня. Постарался сделать комментарии в конфиге как можно более подробными.

Приступим, пожалуй.

Для сборки:

Скачиваем стабильную версию:

Распаковываем:

Переходим в папку с исходниками:

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

Добавить строку:

Возвращаемся на уровень выше

Собираем

Создаем директорию под лог-файлы, копируем бинарник ‘3proxy’ и создаем конфиг ‘3proxy.cfg’ в ‘/usr/local/3proxy’

Пример моего конфига (изменен 25.09.2010):

# Важно указать данное значение, так как только при нем процесс 3proxy уйдет в background
daemon

# Записывать pid текущего процесса в файл
pidfile /usr/local/3proxy/3proxy.pid

# IP адреса
# меняем 192.168.1.2 на ip адрес вашего сервера (internal и external)
internal 192.168.1.2
external 192.168.1.2

# Пропишем правильные серверы имен, посмотрев их на своем сервере в /etc/resolv.conf
nserver 192.168.1.1

# Оставим размер кэша для запросов DNS по умолчанию
nscache 65536
# Равно как и таймауты
timeouts 1 5 30 60 180 1800 15 60

# Создаем двух пользователей zerochaos и zchaos и назначаем им пароли
users zerochaos:CL:password
users zchaos:CL:password

# Путь к логам и формат лога, к имени лога будет добавляться дата создания
log /usr/local/3proxy/logs/3proxy.log D
logformat «- +_L%t.%. %N.%p %E %U %C:%c %R:%r %O %I %h %T»
rotate 30

# Конфигурация FTP (ftp и icq), Web-proxy (http и https), SOCKS5-proxy
flush
auth strong
maxconn 32
# разрешим использовать прокси только тем пользователям, которых добавили в самом начале конфига и с определенным IP
allow zerochaos,zchaos 192.168.1.4,95.95.95.95 * * *
# запустим ftp прокси на порту 3127
#ftppr -p3127
# запустим web прокси на порту 3128
proxy -p3128
# запустим socks прокси на порту 3129
#socks -p3129

# Запустить административный веб-интерфейс на порту 8081
#admin -p8081

# Ограничиваем толщину канала для каждого пользователя, zerochaos и zchaos в 20000 bps
#bandlimin 20000 zerochaos,zchaos
#bandlimin 10000 test

# Отслеживать изменения в файле конфигурации
#monitor /usr/local/3proxy/3proxy.cfg

# Запускаем сервер от пользователя nobody
# (возможно в вашей ОС uid и gid пользователя nobody будут другими, для их определения воспользуйтесь командой id nobody)
setgid 65534
setuid 65534

Выставляем права

Создаем init-script ‘3proxy’ в ‘/etc/init.d’ (переписан с нуля 25.09.2010, идущий по умолчанию с дистрибутивом, иногда запускал 3proxy в двух экземплярах)

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/local/3proxy/3proxy
DAEMON_OPTS=/usr/local/3proxy/3proxy.cfg
NAME=3proxy
DESC=3proxy

test -f $DAEMON || exit 0

set -e

case «$1» in
start)
echo -n «Starting $DESC: »
start-stop-daemon —start —quiet —pidfile /usr/local/3proxy/$NAME.pid \
—exec $DAEMON $DAEMON_OPTS
echo «done.»
;;
stop)
echo -n «Stopping $DESC: »
start-stop-daemon —stop —quiet —pidfile /usr/local/3proxy/$NAME.pid \
—exec $DAEMON
echo «done.»
;;
*)
N=/etc/init.d/$NAME
# echo «Usage: $N {start|stop|restart|reload|force-reload}» >&2
echo «Usage: $N {start|stop}» >&2
exit 1
;;
esac

exit 0

Выставляем права и добавляем в автозагрузку:

Запускаем прокси-сервер

Проверяем слушается ли наш порт:

Ну и проверим висит ли наш процесс:

Анонимность Tinyproxy

По уровню анонимности HTTP прокси разделяются на несколько видов:

• Прозрачные — передают в HTTP заголовках реальный ip-адрес клиента и указывают на факт использования прокси-сервера (отправляется заголовок что при подключении используется прокси-сервер). Анонимности нет.
• Анонимные — указывают на факт использования прокси-сервера, но не раскрывают реальный ip-адрес клиента. Средний уровень анонимности.
• Элитные — не передают реального ip-адреса и не указывают на использование прокси. Высокий уровень анонимности.

Уровень анонимности определяется передачей специфических HTTP заголовков при каждом подключении к конечному узлу. По умолчанию Tinyproxy передает заголовок указывающий название и версию сервера, но не передает реального ip-адреса клиента, то есть обеспечивает средний уровень анонимности.

С помощью сервиса FoxTools можно просмотреть заголовки отправленные вашим прокси-сервером. Вот так выглядят заголовки по умолчанию.

На изображении видно что прокси-сервер передал свое название и версию. Но ничего указывающего на реальный ip-адрес клиента нет. Адрес 93.170.169.118 — это ip-адрес моего сайта и по совместительству прокси-сервера, поэтому я его не прячу.

Чтобы не передавать версию сервера и тем самым не указывать на использование прокси, нужно раскомментировать DisableViaHeader и выставить значение Yes.

DisableViaHeader Yes

Мы добились высокого уровня анонимности (элитный прокси) заголовок Via исчез и ничего не указывает на использование прокси-сервера.

По умолчанию присутствует включенная директива ViaProxyName «tinyproxy». Если ее отключить (закомментировать), то прокси сервер вместе со своей версией будет передавать еще и название вашего хоста.

XTinyproxy — еще одна из важнейших директив. По умолчанию она отключена и включать ее не стоит, она должна быть или закомментирована или выставлена в значение No. Именно она передает ваш реальный ip-адрес!

#XTinyproxy Yes

или так:

XTinyproxy No

Вот что бывает если включить XTinyproxy.

С анонимностью разобрались, в итоге получили следующий минимальный конфиг, который я рекомендую использовать.

# Пользователь и группа
User nobody
Group nogroup

# Порт (НЕ ЗАБУДЬТЕ ОТКРЫТЬ ЕГО В ФАЕРВОЛЕ!!!)
Port 8888

# Таймаут
Timeout 300

# Дефолтный html-файл ошибок
DefaultErrorFile "/usr/share/tinyproxy/default.html"

# html stat файл
StatFile "/usr/share/tinyproxy/stats.html"

# Лог-файл
Logfile "/var/log/tinyproxy/tinyproxy.log"

# Уровень логгирования
LogLevel Info

# Pid-файл
PidFile "/var/run/tinyproxy/tinyproxy.pid"

# Максимальное количество одновременно подключенных клиентов.
MaxClients 20

# Минимальное и максимальное количество рабочих процессов.
MinSpareServers 5
MaxSpareServers 20

# Количество процессов одновременно запускающихся при старте сервера 
StartServers 10

# Количество соединений на один процесс, 0 по дефолту
MaxRequestsPerChild 0

# Разрешаем локальные соединения
Allow 127.0.0.1

# Разрешаем соединения от клиента (ваш ip-адрес или подсеть)
Allow XXX.XXX.XXX.XXX

# Разрешаем соединения по методу CONNECT для работы с HTTPS сайтами
ConnectPort 443
ConnectPort 563

# Имя прокси заголовка
ViaProxyName "tinyproxy"

# Отключаем Via-заголовки передающие версию сервера
DisableViaHeader Yes

# Отключаем передачу реального ip-адреса клиента
XTinyproxy No

Для применения настроек перезапустим Tinyproxy.

systemctl restart tinyproxy

Чтобы сервер не разжирался оперативной памятью будем перезапускать его каждые сутки ровно в 23:50. Добавим задание в cron.

crontab -e

Добавить в файл, сохранить и выйти.

# Перезапуск tinyproxy в 23:50
50 23 * * * systemctl restart tinyproxy

На этом все

Спасибо за внимание