|
936
|
1 <!--
|
|
|
2 Copyright (C) Nginx, Inc.
|
|
|
3 -->
|
|
|
4
|
|
|
5 <!DOCTYPE article SYSTEM "../../../dtd/article.dtd">
|
|
|
6
|
|
|
7 <article name="Руководство для начинающих"
|
|
|
8 link="/ru/docs/beginners_guide.html"
|
|
|
9 lang="ru"
|
|
|
10 rev="1">
|
|
|
11
|
|
|
12 <section>
|
|
|
13
|
|
|
14 <para>
|
|
|
15 В этом руководстве даётся начальное введение в nginx и описываются
|
|
|
16 некоторые простые задачи, которые могут быть решены с его помощью.
|
|
|
17 Предполагается, что nginx уже установлен на компьютере читателя.
|
|
|
18 Если нет, см. <link doc="install.xml"/>.
|
|
|
19 В этом руководстве описывается, как запустить и остановить nginx
|
|
|
20 и перезагрузить его конфигурацию,
|
|
|
21 объясняется, как устроен конфигурационный файл, и описывается,
|
|
|
22 как настроить nginx для раздачи статического содержимого, как
|
|
|
23 настроить прокси-сервер на nginx, и как связать nginx с приложением
|
|
|
24 FastCGI.
|
|
|
25 </para>
|
|
|
26
|
|
|
27 <para>
|
|
|
28 У nginx есть один главный и несколько рабочих процессов.
|
|
|
29 Основная задача главного процесса — чтение и проверка конфигурации
|
|
|
30 и управление рабочими процессами.
|
|
|
31 Рабочие процессы выполняют фактическую обработку запросов.
|
|
|
32 nginx использует
|
|
|
33 модель, основанную на событиях, и зависящие от операционной системы
|
|
|
34 механизмы для эффективного распределения запросов между рабочими процессами.
|
|
|
35 Количество рабочих процессов задаётся в конфигурационном файле и
|
|
|
36 может быть фиксированным для данной конфигурации или автоматически
|
|
|
37 устанавливаться равным числу доступных процессорных ядер (см.
|
|
|
38 <link doc="ngx_core_module.xml" id="worker_processes"/>).
|
|
|
39 </para>
|
|
|
40
|
|
|
41 <para>
|
|
|
42 Как работают nginx и его модули, определяется в конфигурационном файле.
|
|
|
43 По умолчанию, конфигурационный файл называется <path>nginx.conf</path>
|
|
|
44 и расположен в каталоге
|
|
|
45 <path>/usr/local/nginx/conf</path>,
|
|
|
46 <path>/etc/nginx</path> или
|
|
|
47 <path>/usr/local/etc/nginx</path>.
|
|
|
48 </para>
|
|
|
49
|
|
|
50 </section>
|
|
|
51
|
|
|
52
|
|
|
53 <section id="control" name="Запуск, остановка, перезагрузка конфигурации">
|
|
|
54
|
|
|
55 <para>
|
|
|
56 Чтобы запустить nginx, нужно выполнить исполняемый файл.
|
|
|
57 Когда nginx запущен, им можно управлять, вызывая исполняемый файл с
|
|
|
58 параметром <literal>-s</literal>.
|
|
|
59 Используйте следующий синтаксис:
|
|
|
60 <programlisting>
|
|
|
61 nginx -s <i>сигнал</i>
|
|
|
62 </programlisting>
|
|
|
63 Где <i>сигнал</i> может быть одним их нижеследующего:
|
|
|
64 <list type="bullet">
|
|
|
65 <listitem>
|
|
|
66 <literal>stop</literal>—быстрое завершение
|
|
|
67 </listitem>
|
|
|
68 <listitem>
|
|
|
69 <literal>quit</literal>—плавное завершение
|
|
|
70 </listitem>
|
|
|
71 <listitem>
|
|
|
72 <literal>reload</literal>—перезагрузка конфигурационного файла
|
|
|
73 </listitem>
|
|
|
74 <listitem>
|
|
|
75 <literal>reopen</literal>—переоткрытие лог-файлов
|
|
|
76 </listitem>
|
|
|
77 </list>
|
|
|
78 Например, чтобы остановить процессы nginx с ожиданием окончания
|
|
|
79 обслуживания текущих запросов рабочими процессами, можно выполнить
|
|
|
80 следующую команду:
|
|
|
81 <programlisting>
|
|
|
82 nginx -s quit
|
|
|
83 </programlisting>
|
|
|
84 <note>Команда должна быть выполнена под тем же
|
|
|
85 пользователем, под которым был запущен nginx.</note>
|
|
|
86 </para>
|
|
|
87
|
|
|
88 <para>
|
|
|
89 Изменения, сделанные в конфигурационном файле,
|
|
|
90 не будут применены, пока команда перезагрузить конфигурацию не будет
|
|
|
91 вручную отправлена nginx’у или он не будет перезапущен.
|
|
|
92 Для перезагрузки конфигурации выполните:
|
|
|
93 <programlisting>
|
|
|
94 nginx -s reload
|
|
|
95 </programlisting>
|
|
|
96 </para>
|
|
|
97
|
|
|
98 <para>
|
|
|
99 Получив сигнал, главный процесс проверяет правильность синтаксиса нового
|
|
|
100 конфигурационного файла и пытается применить конфигурацию, содержащуюся
|
|
|
101 в нём.
|
|
|
102 Если это ему удаётся, главный процесс запускает новые рабочие процессы
|
|
|
103 и отправляет сообщения старым рабочим процессам с требованием завершиться.
|
|
|
104 В противном случае, главный процесс откатывает изменения и продолжает
|
|
|
105 работать со старой конфигурацией.
|
|
|
106 Старые рабочие процессы, получив команду завершиться,
|
|
|
107 прекращают принимать новые запросы и продолжают обслуживать текущие запросы
|
|
|
108 до тех пор, пока все такие запросы не будут обслужены.
|
|
|
109 После это старые рабочие процессы завершаются.
|
|
|
110 </para>
|
|
|
111
|
|
|
112 <para>
|
|
|
113 Посылать сигналы процессам nginx можно также средствами Unix,
|
|
|
114 такими как утилита <command>kill</command>.
|
|
|
115 В этом случае сигнал отправляется напрямую процессу с данным ID.
|
|
|
116 ID главного процесса nginx записывается по умолчанию в файл
|
|
|
117 <path>nginx.pid</path> в каталоге
|
|
|
118 <path>/usr/local/nginx/logs</path> или
|
|
|
119 <path>/var/run</path>.
|
|
|
120 Например, если ID главного процесса равен 1628, для отправки сигнала QUIT,
|
|
|
121 который приведёт к плавному завершению nginx, нужно выполнить:
|
|
|
122 <programlisting>
|
|
|
123 kill -s QUIT 1628
|
|
|
124 </programlisting>
|
|
|
125 Для просмотра списка всех запущенных процессов nginx может быть использована
|
|
|
126 утилита <command>ps</command>, например, следующим образом:
|
|
|
127 <programlisting>
|
|
|
128 ps -ax | grep nginx
|
|
|
129 </programlisting>
|
|
|
130 Дополнительную информацию об отправке сигналов процессам nginx
|
|
|
131 можно найти в <link doc="control.xml"/>.
|
|
|
132 </para>
|
|
|
133
|
|
|
134 </section>
|
|
|
135
|
|
|
136
|
|
|
137 <section id="conf_structure" name="Структура конфигурационного файла">
|
|
|
138
|
|
|
139 <para>
|
|
|
140 nginx состоит из модулей, которые настраиваются директивами, указанными
|
|
|
141 в конфигурационном файле.
|
|
|
142 Директивы делятся на простые и блочные.
|
|
|
143 Простая директива состоит из имени и параметров, разделённых пробелами,
|
|
|
144 и оканчивается точкой с запятой (<literal>;</literal>).
|
|
|
145 Блочная директива устроена так же, как и простая директива, но
|
|
|
146 вместо точки с запятой после имени и параметров следует набор дополнительных
|
|
|
147 инструкций, помещённых внутри фигурных скобок
|
|
|
148 (<literal>{</literal> и <literal>}</literal>).
|
|
|
149 Если у блочной директивы внутри фигурных скобок можно задавать другие
|
|
|
150 директивы, то она называется контекстом (примеры:
|
|
|
151 <link doc="ngx_core_module.xml" id="events"/>,
|
|
|
152 <link doc="http/ngx_http_core_module.xml" id="http"/>,
|
|
|
153 <link doc="http/ngx_http_core_module.xml" id="server"/>
|
|
|
154 и
|
|
|
155 <link doc="http/ngx_http_core_module.xml" id="location"/>).
|
|
|
156 </para>
|
|
|
157
|
|
|
158 <para>
|
|
|
159 Директивы, помещённые в конфигурационном файле вне любого контекста,
|
|
|
160 считаются находящимися в контексте
|
|
|
161 <link doc="ngx_core_module.xml">main</link>.
|
|
|
162 Директивы <literal>events</literal> и <literal>http</literal>
|
|
|
163 располагаются в контексте <literal>main</literal>, <literal>server</literal> —
|
|
|
164 в <literal>http</literal>, а <literal>location</literal> — в
|
|
|
165 <literal>server</literal>.
|
|
|
166 </para>
|
|
|
167
|
|
|
168 <para>
|
|
|
169 Часть строки после символа <literal>#</literal> считается комментарием.
|
|
|
170 </para>
|
|
|
171
|
|
|
172 </section>
|
|
|
173
|
|
|
174
|
|
|
175 <section id="static" name="Раздача статического содержимого">
|
|
|
176
|
|
|
177 <para>
|
|
|
178 Одна из важных задач конфигурации nginx — раздача
|
|
|
179 файлов, таких как изображения или статические HTML-страницы.
|
|
|
180 Рассмотрим пример, в котором в зависимости от запроса файлы будут
|
|
|
181 раздаваться из разных локальных каталогов: <path>/data/www</path>,
|
|
|
182 который содержит HTML-файлы, и <path>/data/images</path>,
|
|
|
183 содержащий файлы с изображениями.
|
|
|
184 Для этого потребуется отредактировать конфигурационный файл и настроить
|
|
|
185 блок
|
|
|
186 <link doc="http/ngx_http_core_module.xml" id="server"/>
|
|
|
187 внутри блока <link doc="http/ngx_http_core_module.xml" id="http"/>
|
|
|
188 с двумя блоками <link doc="http/ngx_http_core_module.xml" id="location"/>.
|
|
|
189 </para>
|
|
|
190
|
|
|
191 <para>
|
|
|
192 Во-первых, создайте каталог <path>/data/www</path> и положите в него файл
|
|
|
193 <path>index.html</path> с любым текстовым содержанием, а также
|
|
|
194 создайте каталог <path>/data/images</path> и положите в него несколько
|
|
|
195 файлов с изображениями.
|
|
|
196 </para>
|
|
|
197
|
|
|
198 <para>
|
|
|
199 Далее, откройте конфигурационный файл.
|
|
|
200 Конфигурационный файл по умолчанию уже включает в себя несколько
|
|
|
201 примеров блока <literal>server</literal>, большей частью закомментированных.
|
|
|
202 Для нашей текущей задачи лучше закомментировать все такие блоки и
|
|
|
203 добавить новый блок <literal>server</literal>:
|
|
|
204 <programlisting>
|
|
|
205 http {
|
|
|
206 server {
|
|
|
207 }
|
|
|
208 }
|
|
|
209 </programlisting>
|
|
|
210 В общем случае конфигурационный файл может содержать несколько блоков
|
|
|
211 <literal>server</literal>,
|
|
|
212 <link doc="http/request_processing.xml">различаемых</link> по портам, на
|
|
|
213 которых они
|
|
|
214 <link doc="http/ngx_http_core_module.xml" id="listen">слушают</link>,
|
|
|
215 и по
|
|
|
216 <link doc="http/server_names.xml">имени сервера</link>.
|
|
|
217 Определив, какой <literal>server</literal> будет обрабатывать запрос,
|
|
|
218 nginx сравнивает URI, указанный в заголовке запроса, с параметрами директив
|
|
|
219 <literal>location</literal>, определённых внутри блока
|
|
|
220 <literal>server</literal>.
|
|
|
221 </para>
|
|
|
222
|
|
|
223 <para>
|
|
|
224 В блок <literal>server</literal> добавьте блок <literal>location</literal>
|
|
|
225 следующего вида:
|
|
|
226 <programlisting>
|
|
|
227 location / {
|
|
|
228 root /data/www;
|
|
|
229 }
|
|
|
230 </programlisting>
|
|
|
231 Этот блок <literal>location</literal> задаёт “<path>/</path>”
|
|
|
232 в качестве префикса, который сравнивается с URI из запроса.
|
|
|
233 Для подходящих запросов добавлением URI к пути, указанному в директиве
|
|
|
234 <link doc="http/ngx_http_core_module.xml" id="root"/>,
|
|
|
235 то есть, в данном случае, к <path>/data/www</path>, получается
|
|
|
236 путь к запрашиваемому файлу в локальной файловой системе.
|
|
|
237 Если есть совпадение с несколькими блоками <literal>location</literal>,
|
|
|
238 nginx выбирает блок c самым длинным префиксом.
|
|
|
239 В блоке <literal>location</literal> выше указан самый короткий префикс,
|
|
|
240 длины один,
|
|
|
241 и поэтому этот блок будет использован, только если не будет совпадения
|
|
|
242 ни с одним из остальных блоков <literal>location</literal>.
|
|
|
243 </para>
|
|
|
244
|
|
|
245 <para>
|
|
|
246 Далее, добавьте второй блок <literal>location</literal>:
|
|
|
247 <programlisting>
|
|
|
248 location /images/ {
|
|
|
249 root /data;
|
|
|
250 }
|
|
|
251 </programlisting>
|
|
|
252 Он будет давать совпадение с запросами, начинающимися с
|
|
|
253 <literal>/images/</literal>
|
|
|
254 (<literal>location /</literal> для них тоже подходит, но указанный там префикс
|
|
|
255 короче).
|
|
|
256 </para>
|
|
|
257
|
|
|
258 <para>
|
|
|
259 Итоговая конфигурация блока <literal>server</literal> должна выглядеть
|
|
|
260 следующим образом:
|
|
|
261 <programlisting>
|
|
|
262 server {
|
|
|
263 location / {
|
|
|
264 root /data/www;
|
|
|
265 }
|
|
|
266
|
|
|
267 location /images/ {
|
|
|
268 root /data;
|
|
|
269 }
|
|
|
270 }
|
|
|
271 </programlisting>
|
|
|
272 Это уже работающая конфигурация сервера, слушающего на стандартном порту 80
|
|
|
273 и доступного на локальном компьютере по адресу
|
|
|
274 <literal>http://localhost/</literal>.
|
|
|
275 В ответ на запросы, URI которых начинаются с <literal>/images/</literal>,
|
|
|
276 сервер будет отправлять файлы из каталога <path>/data/images</path>.
|
|
|
277 Например, на запрос
|
|
|
278 <literal>http://localhost/images/example.png</literal> nginx отправит
|
|
|
279 в ответ файл <path>/data/images/example.png</path>.
|
|
|
280 Если же этот файл не существует, nginx отправит ответ, указывающий на
|
|
|
281 ошибку 404.
|
|
|
282 Запросы, URI которых не начинаются на <literal>/images/</literal>, будут
|
|
|
283 отображены на каталог <path>/data/www</path>.
|
|
|
284 Например, в результате запроса
|
|
|
285 <literal>http://localhost/some/example.html</literal> в ответ будет
|
|
|
286 отправлен файл <path>/data/www/some/example.html</path>.
|
|
|
287 </para>
|
|
|
288
|
|
|
289 <para>
|
|
|
290 Чтобы применить новую конфигурацию, запустите nginx, если он ещё не запущен,
|
|
|
291 или отправьте сигнал <literal>reload</literal> главному процессу nginx,
|
|
|
292 выполнив:
|
|
|
293 <programlisting>
|
|
|
294 nginx -s reload
|
|
|
295 </programlisting>
|
|
|
296 </para>
|
|
|
297
|
|
|
298 <para>
|
|
|
299 <note>
|
|
|
300 В случае если что-то работает не как ожидалось, можно попытаться выяснить
|
|
|
301 причину с помощью файлов <path>access.log</path> и <path>error.log</path>
|
|
|
302 из каталога
|
|
|
303 <path>/usr/local/nginx/logs</path> или
|
|
|
304 <path>/var/log/nginx</path>.
|
|
|
305 </note>
|
|
|
306 </para>
|
|
|
307
|
|
|
308 </section>
|
|
|
309
|
|
|
310
|
|
|
311 <section id="proxy" name="Настройка простого прокси-сервера">
|
|
|
312
|
|
|
313 <para>
|
|
|
314 Одним из частых применений nginx является использование его в качестве
|
|
|
315 прокси-сервера, то есть сервера, который принимает запросы, перенаправляет их
|
|
|
316 на проксируемые сервера, получает ответы от них и отправляет их клиенту.
|
|
|
317 </para>
|
|
|
318
|
|
|
319 <para>
|
|
|
320 Мы настроим базовый прокси-сервер, который будет обслуживать запросы
|
|
|
321 изображений из локального каталога и отправлять все остальные запросы на
|
|
|
322 проксируемый сервер.
|
|
|
323 В этом примере оба сервера будут работать в рамках одного
|
|
|
324 экземпляра nginx.
|
|
|
325 </para>
|
|
|
326
|
|
|
327 <para>
|
|
|
328 Во-первых, создайте проксируемый сервер, добавив ещё один блок
|
|
|
329 <literal>server</literal> в конфигурационный файл nginx со следующим
|
|
|
330 содержимым:
|
|
|
331 <programlisting>
|
|
|
332 server {
|
|
|
333 listen 8080;
|
|
|
334 root /data/up1;
|
|
|
335
|
|
|
336 location / {
|
|
|
337 }
|
|
|
338 }
|
|
|
339 </programlisting>
|
|
|
340 Это будет простой сервер, слушающий на порту 8080
|
|
|
341 (ранее директива <literal>listen</literal> не указывалась, потому что
|
|
|
342 использовался стандартный порт 80) и отображающий все
|
|
|
343 запросы на каталог <path>/data/up1</path> в локальной файловой
|
|
|
344 системе.
|
|
|
345 Создайте этот каталог и положите в него файл <path>index.html</path>.
|
|
|
346 Обратите внимание, что директива <literal>root</literal> помещена в контекст
|
|
|
347 <literal>server</literal>.
|
|
|
348 Такая директива <literal>root</literal> будет использована, когда директива
|
|
|
349 <literal>location</literal>, выбранная для выполнения запроса, не содержит
|
|
|
350 собственной директивы <literal>root</literal>.
|
|
|
351 </para>
|
|
|
352
|
|
|
353 <para>
|
|
|
354 Далее, используйте конфигурацию сервера из предыдущего раздела
|
|
|
355 и видоизмените её, превратив в конфигурацию прокси-сервера.
|
|
|
356 В первый блок <literal>location</literal> добавьте директиву
|
|
|
357 <link doc="http/ngx_http_proxy_module.xml" id="proxy_pass"/>,
|
|
|
358 указав протокол, имя и порт проксируемого сервера в качестве параметра
|
|
|
359 (в нашем случае это <literal>http://localhost:8080</literal>):
|
|
|
360 <programlisting>
|
|
|
361 server {
|
|
|
362 location / {
|
|
|
363 proxy_pass http://localhost:8080;
|
|
|
364 }
|
|
|
365
|
|
|
366 location /images/ {
|
|
|
367 root /data;
|
|
|
368 }
|
|
|
369 }
|
|
|
370 </programlisting>
|
|
|
371 </para>
|
|
|
372
|
|
|
373 <para>
|
|
|
374 Мы изменим второй блок
|
|
|
375 <literal>location</literal>, который на данный момент отображает запросы
|
|
|
376 с префиксом <literal>/images/</literal> на файлы из каталога
|
|
|
377 <path>/data/images</path> так, чтобы он подходил для запросов изображений
|
|
|
378 с типичными расширениями файлов.
|
|
|
379 Изменённый блок <literal>location</literal> выглядит следующим образом:
|
|
|
380 <programlisting>
|
|
|
381 location ~ \.(gif|jpg|png)$ {
|
|
|
382 root /data/images;
|
|
|
383 }
|
|
|
384 </programlisting>
|
|
|
385 Параметром является регулярное выражение, дающее совпадение со всеми
|
|
|
386 URI, оканчивающимися на <path>.gif</path>, <path>.jpg</path> или
|
|
|
387 <path>.png</path>.
|
|
|
388 Регулярному выражению должен предшествовать символ <literal>~</literal>.
|
|
|
389 Соответствующие запросы будут отображены на каталог <path>/data/images</path>.
|
|
|
390 </para>
|
|
|
391
|
|
|
392 <para>
|
|
|
393 Когда nginx выбирает блок <literal>location</literal>,
|
|
|
394 который будет обслуживать запрос, то вначале он проверяет
|
|
|
395 директивы <link doc="http/ngx_http_core_module.xml" id="location"/>,
|
|
|
396 задающие префиксы, запоминая <literal>location</literal> с самым
|
|
|
397 длинным подходящим префиксом, а затем проверяет регулярные выражения.
|
|
|
398 Если есть совпадение с регулярным выражением, nginx выбирает соответствующий
|
|
|
399 <literal>location</literal>, в противном случае берётся запомненный ранее
|
|
|
400 <literal>location</literal>.
|
|
|
401 </para>
|
|
|
402
|
|
|
403 <para>
|
|
|
404 Итоговая конфигурация прокси-сервера выглядит следующим образом:
|
|
|
405 <programlisting>
|
|
|
406 server {
|
|
|
407 location / {
|
|
|
408 proxy_pass http://localhost:8080/;
|
|
|
409 }
|
|
|
410
|
|
|
411 location ~ \.(gif|jpg|png)$ {
|
|
|
412 root /data/images;
|
|
|
413 }
|
|
|
414 }
|
|
|
415 </programlisting>
|
|
|
416 Этот сервер будет фильтровать запросы, оканчивающиеся на
|
|
|
417 <path>.gif</path>, <path>.jpg</path> или <path>.png</path>,
|
|
|
418 и отображать их на каталог <path>/data/images</path> (добавлением URI к
|
|
|
419 параметру директивы <literal>root</literal>) и перенаправлять все остальные
|
|
|
420 запросы на проксируемый сервер, сконфигурированный выше.
|
|
|
421 </para>
|
|
|
422
|
|
|
423 <para>
|
|
|
424 Чтобы применить новую конфигурацию, отправьте сигнал <literal>reload</literal>
|
|
|
425 nginx’у, как описывалось в предыдущих разделах.
|
|
|
426 </para>
|
|
|
427
|
|
|
428 <para>
|
|
|
429 Существует <link doc="http/ngx_http_proxy_module.xml">множество</link>
|
|
|
430 других директив для дальнейшей настройки прокси-соединения.
|
|
|
431 </para>
|
|
|
432
|
|
|
433 </section>
|
|
|
434
|
|
|
435
|
|
|
436 <section id="fastcgi" name="Настройка проксирования FastCGI">
|
|
|
437
|
|
|
438 <para>
|
|
|
439 nginx можно использовать для перенаправления запросов на FastCGI-серверы.
|
|
|
440 На них могут исполняться приложения, созданные с использованием
|
|
|
441 разнообразных фреймворков и языков программирования, например, PHP.
|
|
|
442 </para>
|
|
|
443
|
|
|
444 <para>
|
|
|
445 Базовая конфигурация nginx для работы с проксируемым FastCGI-сервером
|
|
|
446 включает в себя использование директивы
|
|
|
447 <link doc="http/ngx_http_fastcgi_module.xml" id="fastcgi_pass"/>
|
|
|
448 вместо директивы <literal>proxy_pass</literal>,
|
|
|
449 и директив <link doc="http/ngx_http_fastcgi_module.xml" id="fastcgi_param"/>
|
|
|
450 для настройки параметров, передаваемых FastCGI-серверу.
|
|
|
451 Представьте, что FastCGI-сервер доступен по адресу
|
|
|
452 <literal>localhost:9000</literal>.
|
|
|
453 Взяв за основу конфигурацию прокси-сервера из предыдущего раздела,
|
|
|
454 замените директиву <literal>proxy_pass</literal> на директиву
|
|
|
455 <literal>fastcgi_pass</literal> и измените параметр на
|
|
|
456 <literal>localhost:9000</literal>.
|
|
|
457 В PHP параметр <literal>SCRIPT_FILENAME</literal> используется для
|
|
|
458 определения имени скрипта, а в параметре <literal>QUERY_STRING</literal>
|
|
|
459 передаются параметры запроса.
|
|
|
460 Получится следующая конфигурация:
|
|
|
461 <programlisting>
|
|
|
462 server {
|
|
|
463 location / {
|
|
|
464 fastcgi_pass localhost:9000;
|
|
|
465 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
|
|
|
466 fastcgi_param QUERY_STRING $query_string;
|
|
|
467 }
|
|
|
468
|
|
|
469 location ~ \.(gif|jpg|png)$ {
|
|
|
470 root /data/images;
|
|
|
471 }
|
|
|
472 }
|
|
|
473 </programlisting>
|
|
|
474 Таким образом будет настроен сервер, который будет перенаправлять
|
|
|
475 все запросы, кроме запросов статических изображений, на проксируемый
|
|
|
476 сервер, работающий по адресу <literal>localhost:9000</literal>,
|
|
|
477 по протоколу FastCGI.
|
|
|
478 </para>
|
|
|
479
|
|
|
480 </section>
|
|
|
481
|
|
|
482 </article>
|
