WEB-приложение Сведение отчетности ((раздел целиком))

WEB-приложение Сведение отчетности- Использование серверного proxy (раздел целиком) (29.04.2026) | (одним файлом)

Использование серверного proxy
Допустим, мы имеем следующую схему подключения: Допустим, на сервере, обозначенном как "наш сервер", установлен наш сервис. "Наш сервер" слушает IP-адрес внутренней сети 192.168.4.110, порт 8090. В таком случае он доступен пользователям во внутренней сети через url http://192.168.4.110:8090. На сервере, обозначенном как "Proxy-сервер", установлен web-сервер apache, конфигурационный файл которого содержит, помимо прочего, следующие строки:
    01Listen 8099
    02  ...
    03  LoadModule proxy_module modules/mod_proxy.so
    04  ...
    05  ProxyPass /mysite/mysite1/mysite2/ http://192.168.4.110:8090/
    06  ...
    07  <Proxy /mysite/mysite1/mysite2/*>
    08    Order allow,deny
    09    Allow from all
    10    ...
    11  </Proxy>
    12  ....
Proxy-сервер имеет внешний IP 212.158.161.21. То есть, все обращения, поступающие на proxy-сервер на url вида http://212.158.161.21:8099/mysite/mysite1/mysite2/.... будут перенаправлены им на наш сервер, а ответ нашего сервера будет возвращен удаленному клиенту (в этом смысл работы механизма proxy). Благодаря этому, сервис доступен "снаружи" через url http://212.158.161.21:8099/mysite/mysite1/mysite2/parusjs/index.html (вам придется указывать полный путь именно в таком виде, иначе мы не сможем разрешить относительные ссылки на страницах). При настройке удаленного доступа приложений Win32 к этому серверу, вам необходимо указать в поле " Хост сервера " строку " 212.158.161.21:8099 " (без кавычек), в поле " Путь серверного proxy " указать строку " /mysite/mysite1/mysite2 " (без кавычек). Во всех случаях номера стандартных портов можно не указывать, а IP-адреса заменить соответствующими им доменными именами. При использовании серверного proxy "Наш сервер" будет лишен возможности получить реальные IP-адреса удаленных пользователей, все запросы он будет видеть приходящими с одного и того же адреса. Если вы используете серверный proxy, то вы лишаетесь возможности протоколировать IP-адреса (протоколирование должно быть возложено на proxy-сервер) в поле "Способ идентификации сессии" на странице " Параметры сетевых настроек " не сможете использовать способы, опирающиеся на IP-адрес (фактически, вам доступен только способ "Использовать идентификатор"). Это приведет к невозможности работы с сервисом пользователей, не имеющих соединения с постоянным IP-адресом.

1. Поддержка соединения для запросов выполняющихся длительное время (более 1-2 мин)
1. При работе тонкого клиента напрямую с сервером приложений, подобной проблемы не возникает, т.к. тонкий клиент и сервер приложений самостоятельно поддерживают длительные запросы к СУБД, без стороннего воздействия. При работе тонкого клиента через серверный прокси, запросы, выполняющиеся на сервере СУБД, продолжительное время (более 1-2 мин), могут быть расценены клиентом как запросы, на которые не поступил ответ. В результате, взаимодействие с сервером прекращается, и клиент получает ошибку Cannot initiate intercommunication with remote server. Please, check provided address information. Для решения данной проблемы, необходимо помочь серверу приложений определить, что он работает через серверный прокси (reverse proxy). Для этого необходимо настроить 2 момента: Запросы клиентов, перенаправляемые серверным прокси, на сервер приложений, должны содержать какой-то из следующих заголовков: X-Original-URL X-Forwarded-For X-Real-IP Значение этих заголовков не имеет значения, важно просто наличие одного из них.
   Пример | В nginx, в качестве одного из вариантов, можно указать в его конфиге - proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
2. Таймауты серверного прокси для ожидания ответа от сервера приложений, должны быть достаточно большими, чтобы длительный запрос успел выполниться в СУБД.
   Пример | В nginx, в его конфиге нужно указать - proxy_read_timeout 300s; #вместо 300 сек укажите свое значение, по умолчанию nginx использует 1 мин.