1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
|
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
<!-- English Revision: 344971:1856036 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<modulesynopsis metafile="mod_proxy.xml.meta">
<name>mod_proxy</name>
<description>HTTP/1.1 プロキシ/ゲートウェイサーバ</description>
<status>Extension</status>
<sourcefile>mod_proxy.c</sourcefile>
<identifier>proxy_module</identifier>
<summary>
<note type="warning"><title>警告</title>
<p><a href="#access"
>サーバを安全にする</a>まで <directive module="mod_proxy"
>ProxyRequests</directive> は有効にしないでください。
オープンプロキシサーバはあなた自身のネットワークにとっても、
インターネット全体にとっても危険です。</p>
</note>
<p>このモジュールは Apache のプロキシ/ゲートウェイ機能を実装しています。
<code>AJP13</code> (Apache JServe Protocol version 1.3),
<code>FTP</code>, <code>CONNECT</code> (SSL 用),
<code>HTTP/0.9</code>, <code>HTTP/1.0</code>, <code>HTTP/1.1</code>
のプロキシ機能を実装しています。これらのプロトコルやその他のプロトコル用の
プロキシ機能を持った、他のモジュールに接続するようにも設定できます。</p>
<p>Apache のプロキシ機能は <module>mod_proxy</module> の他に、
いくつかのモジュールに分割されています:
<module>mod_proxy_http</module>, <module>mod_proxy_ftp</module>,
<module>mod_proxy_ajp</module>, <module>mod_proxy_balancer</module>,
<module>mod_proxy_connect</module> です。ですから、
特定のプロキシの機能を使いたい場合は、<module>mod_proxy</module> <em>と</em>
該当するモジュールをサーバに (コンパイル時に静的に行なうか
<directive module="mod_so">LoadModule</directive> で動的に読み込むかして)
組み込む必要があります。</p>
<p>これに加えて、他のモジュールによって拡張機能が提供されています。
キャッシュは <module>mod_cache</module> と関連モジュールで
提供されています。SSL/TLS で遠隔サーバに接続する機能は
<module>mod_ssl</module> の <code>SSLProxy*</code> ディレクティブで
提供されています。これらの機能を利用するためには、該当するモジュールを
組み込んで設定しなければなりません。</p>
</summary>
<seealso><module>mod_cache</module></seealso>
<seealso><module>mod_proxy_http</module></seealso>
<seealso><module>mod_proxy_ftp</module></seealso>
<seealso><module>mod_proxy_connect</module></seealso>
<seealso><module>mod_proxy_balancer</module></seealso>
<seealso><module>mod_ssl</module></seealso>
<section id="forwardreverse"><title>フォワードプロキシとリバースプロキシ</title>
<p>Apache は<dfn>フォワード</dfn>プロキシとしても、
<dfn>リバース</dfn>プロキシとしても設定することができます。</p>
<p>通常の<dfn>フォワードプロキシ</dfn>はクライアントと
<em>オリジンサーバ</em> <transnote>コンテンツ生成元のサーバ</transnote>
の間に位置する中間サーバです。
オリジンサーバからコンテンツを取得する過程では、クライアントは
行き先としてオリジンサーバを指定しつつプロキシにリクエストを送り、
プロキシはオリジンサーバからコンテンツ取得のリクエストを送り、
コンテンツが取得できればそれをクライアントに返します。
クライアントが他のサイトにフォワードプロクシ経由でアクセスするには、
特別にそれ用の設定をしなければなりません。</p>
<p>フォワードプロキシの一般的な使用方法は、ファイアウォールによって
制限されている内部のクライアントにインターネットへのアクセスを
提供するものです。フォワードプロキシはネットワークの使用量を
減らすために (<module>mod_cache</module> で提供されている)
キャッシュ機能を用いることもできます。</p>
<p>フォワードプロキシは <directive
module="mod_proxy">ProxyRequests</directive> ディレクティブで
有効になります。フォワードプロキシでは、クライアントは本当の身元を
隠して任意のサイトにアクセスできるようになるため、フォワードプロキシを
有効にする前に、承認されたクライアントのみがプロキシにアクセスできるように
<a href="#access">サーバを安全にする</a>ことが重要です。</p>
<p>一方<dfn>リバースプロキシ</dfn>は、クライアントには普通の
ウェブサーバのように見えます。クライアント側に特別な設定は必要ありません。
クライアントはリバースプロキシの名前空間に対して通常のコンテンツへの
リクエストを行ないます。プロキシはリクエストをどこに送れば良いかを判定し、
あたかも自分自身がオリジンサーバであったかのようにクライアントに
コンテンツを返します。</p>
<p>リバースプロキシのよくある利用方法は、インターネットユーザに
ファイアウォールの中にあるサーバにアクセスを与えるというものです。
リバースプロキシは複数のバックエンドサーバへ負荷分散をするために
使ったり、遅いバックエンドエンドサーバのためにキャッシュ機能を提供したり
するために使えます。また、リバースプロキシは複数のサーバを
同じ URL 空間にまとめるために使うこともできます。</p>
<p>リバースプロキシは <directive
module="mod_proxy">ProxyPass</directive> ディレクティブや
<directive
module="mod_rewrite">RewriteRule</directive> ディレクティブの
<code>[P]</code> フラグを使うことで有効になります。リバースプロキシの
設定のために <directive
module="mod_proxy">ProxyRequests</directive> を設定する必要は
<em>ありません</em>。</p>
</section> <!-- /forwardreverse -->
<section id="examples"><title>基本の例</title>
<p>以下の例は手始めの簡単な例です。個々のディレクティブの意味は
それぞれの説明をお読みください。</p>
<p>またキャッシュ機能を有効にしたい場合は、<module>mod_cache</module>
の説明を読んでください。</p>
<example><title>フォワードプロキシ</title>
ProxyRequests On<br />
ProxyVia On<br />
<br />
<Proxy *><br />
<indent>
Order deny,allow<br />
Deny from all<br />
Allow from internal.example.com<br />
</indent>
</Proxy>
</example>
<example><title>リバースプロキシ</title>
ProxyRequests Off<br />
<br />
<Proxy *><br />
<indent>
Order deny,allow<br />
Allow from all<br />
</indent>
</Proxy><br />
<br />
ProxyPass /foo http://foo.example.com/bar<br />
ProxyPassReverse /foo http://foo.example.com/bar
</example>
</section> <!-- /examples -->
<section id="access"><title>プロキシへのアクセス制御</title>
<p>プロキシのアクセスは以下のように <directive
module="mod_proxy" type="section">Proxy</directive> コンテナの中に
ディレクティブを書くことで制御できます:</p>
<example>
<Proxy *><br />
<indent>
Order Deny,Allow<br />
Deny from all<br />
Allow from 192.168.0<br />
</indent>
</Proxy>
</example>
<p>アクセス制御のためのディレクティブのより詳しい情報は
<module>mod_authz_host</module> をお読みください。</p>
<p>(<directive
module="mod_proxy">ProxyRequests</directive> ディレクティブを
使って) フォワードプロキシを設定している場合は、厳しくアクセス
制限を行なうことが非常に大切です。そうしないと、任意のクライアントが
身元を明かすことなく任意のホストにアクセスするためにサーバを使うことが
できてしまいます。これはあなた自身のネットワークにとっても、インターネット
全体にとっても危険なことです。(<code>ProxyRequests Off</code> にして
<directive
module="mod_proxy">ProxyPass</directive> ディレクティブを使って)
リバースプロキシを使っている場合には、クライアントはあなたが明示的に
設定したホストにしかアクセスできないため、フォワードプロキシのとき
ほどアクセス制御に力を注がなくても大丈夫です。</p>
</section> <!-- /access -->
<section id="startup"><title>遅い起動</title>
<p><directive module="mod_proxy"
>ProxyBlock</directive> ディレクティブを使っている場合、
後のテストのために起動時にホストの
IP アドレスが調べられてキャッシュされます。ホスト名のルックアップの
速さによっては、数秒 (かそれ以上) かかるかもしれません。</p>
</section> <!-- /startup -->
<section id="intranet"><title>イントラネットプロキシ</title>
<p>イントラネットにある Apache プロキシサーバは外部へのリクエストを
会社のファイアウォールを通して送らなければなりません。(このためには
個々の <var>scheme</var> についてそれぞれ、ファイアウォールの
プロキシにフォワードされるように
<directive module="mod_proxy">ProxyRemote</directive> ディレクティブを
設定してください)。しかしイントラネット内のリソースにアクセスするときは、
ファイアウォールを通さないでもアクセスできます。
どのホストがイントラネットに属し、直接アクセスすべきかを指定するには、
<directive module="mod_proxy">NoProxy</directive> ディレクティブが
役に立ちます。</p>
<p>イントラネット内のユーザは WWW のリクエストでローカルドメインを
省略することがよくあります。<code>http://somehost.example.com/</code>
というリクエストの代わりに "http://somehost/" をリクエストしたりします。
このようなリクエストを受け付け、サーバに設定されているローカルドメインが
暗黙のうちに使われていると解釈して、単純にリクエストを処理するものも
商用プロキシサーバの中にはあります。
サーバが <a
href="#proxyrequests">プロキシのサービス用に設定されていて</a>
<directive module="mod_proxy">ProxyDomain</directive> ディレクティブが
使用された場合には、Apache はクライアントにリダイレクト応答を送って、
正しい、完全な (<transnote>fully qualified</transnote>)
サーバのアドレスに送ることができます。このように
リダイレクトすると、ユーザのブックマークが正しい完全なホスト名を含む
ことにもなるため、より好ましい方法と言えるでしょう。</p>
</section> <!-- /intranet -->
<section id="envsettings"><title>プロトコルの調整</title>
<p>Keepalive や HTTP/1.1 を適切に実装していないアプリケーションサーバに対して
<module>mod_proxy</module> がリクエストを送信する場合、
HTTP/1.0 を使って keepalive を無しにしてリクエストを送るようにする
環境変数が二つあります。これらは <directive module="mod_env"
>SetEnv</directive> ディレクティブで設定します。</p>
<p><code>force-proxy-request-1.0</code> と <code>proxy-nokeepalive</code>
がその環境変数です。</p>
<example>
<Location /buggyappserver/><br />
<indent>
ProxyPass http://buggyappserver:7001/foo/<br />
SetEnv force-proxy-request-1.0 1<br />
SetEnv proxy-nokeepalive 1<br />
</indent>
</Location>
</example>
</section> <!-- /envsettings -->
<section id="request-bodies"><title>リクエストボディ</title>
<p>POST メソッドなどのリクエストには、リクエストボディがあります。
HTTP プロトコル仕様によると、ボディのあるリクエストは chunked
転送を使うか、<code>Content-Length</code>
ヘッダを送信しなければなりません。
このようなリクエストをオリジンサーバに送信する場合、
<module>mod_proxy_http</module> は常に <code>Content-Length</code>
を送ろうと試みます。しかし。ボディが大きく、オリジナルのリクエストで
chunked 転送が使われている場合、上流へのリクエストに
chunked 転送も使われます。
この挙動は <a href="../env.html">環境変数</a>で制御できます。
<code>proxy-sendcl</code> を設定すると、可能な限り常に
<code>Content-Length</code> を付与して、
上流サーバに送信するようになります。
逆に <code>proxy-sendchunked</code> を設定すると、リソース消費を抑え、
chnked エンコードを使って送信するようになります。</p>
</section> <!-- /request-bodies -->
<directivesynopsis>
<name>BalancerMember</name>
<description>Add a member to a load balancing group</description>
<contextlist><context>directory</context></contextlist>
<usage><p>Documentation not yet translated. Please see English version of document.</p></usage>
</directivesynopsis>
<directivesynopsis type="section">
<name>Proxy</name>
<description>プロキシされるリソースに適用されるコンテナ</description>
<syntax><Proxy <var>wildcard-url</var>> ...</Proxy></syntax>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
<p><directive type="section">Proxy</directive> セクション中の
ディレクティブはマッチするプロキシされるコンテンツにのみ適用されます。
シェル形式のワイルドカードが使えます。</p>
<p>例えば、次の設定は <code>yournetwork.example.com</code> の
ホストにのみプロキシサーバを経由したアクセスを許可します:</p>
<example>
<Proxy *><br />
<indent>
Order Deny,Allow<br />
Deny from all<br />
Allow from yournetwork.example.com<br />
</indent>
</Proxy>
</example>
<p>次の例は <code>example.com</code> の <code>foo</code> ディレクトリの
すべてのファイルに対して、プロキシサーバを通して送られたときには
<code>INCLUDES</code> フィルタを通して送るように設定します:</p>
<example>
<Proxy http://example.com/foo/*><br />
<indent>
SetOutputFilter INCLUDES<br />
</indent>
</Proxy>
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>ProxyBadHeader</name>
<description>応答におかしなヘッダがある場合の扱い方を決める</description>
<syntax>ProxyBadHeader IsError|Ignore|StartBody</syntax>
<default>ProxyBadHeader IsError</default>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<compatibility>2.0.44 以降</compatibility>
<usage>
<p><directive>ProxyBadHeader</directive> ディレクティブは構文的に
間違ったヘッダ (<em>つまり</em> コロンを含まないもの) を受け取ったときに
<module>mod_proxy</module> がどう振る舞うかを決めます。以下の引数を
取ることができます:</p>
<dl>
<dt><code>IsError</code></dt>
<dd>リクエストを中止して 502 (Bad Gateway) 応答を返す。
これがデフォルトの動作です。</dd>
<dt><code>Ignore</code></dt>
<dd>間違ったヘッダ行をそもそも存在しなかったものとして扱う。</dd>
<dt><code>StartBody</code></dt>
<dd>間違ったヘッダ行を受け取ったら、ヘッダの読み込みを終了して、
それ以降の残りをボディとして扱う。これはヘッダとボディの間に空行を入れ忘れて
しまっているような、きちんと動作していないバックエンドサーバがあるときに、
問題を回避するのに役に立ちます。</dd>
</dl>
</usage>
</directivesynopsis>
<directivesynopsis type="section">
<name>ProxyMatch</name>
<description>正規表現でのマッチによるプロキシリソース用のディレクティブコンテナ</description>
<syntax><ProxyMatch <var>regex</var>> ...</ProxyMatch></syntax>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
<p><directive type="section">ProxyMatch</directive> は URL のマッチに
<glossary ref="regex">正規表現</glossary> を用いることを除いて
<directive type="section">Proxy</directive> ディレクティブと同じです。</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>ProxyPreserveHost</name>
<description>プロキシリクエストに、受け付けた Host HTTP ヘッダを使う</description>
<syntax>ProxyPreserveHost On|Off</syntax>
<default>ProxyPreserveHost Off</default>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<compatibility>Apache 2.0.31 以降で使用可能</compatibility>
<usage>
<p>このオプションが有効になっている場合、<directive>ProxyPass</directive>
で指定したホスト名の代わりに、受け付けたリクエストの Host: 行を
プロキシ先のホストに送ります。</p>
<p>このオプションは通常は <code>Off</code> に設定してください。
ほとんどの場合、これは大量の名前ベースのバーチャルホスティングを行なっていて、
元々の Host ヘッダをバックエンドサーバが解釈する必要のあるときのような、
特別な設定が必要な場合にのみ有用です。</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>ProxyRequests</name>
<description>フォワード (標準の) プロキシリクエストを有効にする</description>
<syntax>ProxyRequests On|Off</syntax>
<default>ProxyRequests Off</default>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
<p>これは Apache のフォワードプロキシサーバとしての動作を
有効もしくは無効にします。(ProxyRequests を <code>Off</code> に
設定しても、<directive module="mod_proxy">ProxyPass</directive>
の設定は無効になりません。)</p>
<p>通常のリバースプロキシの設定では、このオプションは <code>Off</code>
に設定してください。</p>
<p>HTTP や FTP サイトへのプロキシの機能を有効にしたい場合は、
<module>mod_proxy_http</module> や <module>mod_proxy_ftp</module> が
サーバに組み込まれていなければなりません。</p>
<note type="warning"><title>警告</title>
<p><a href="#access"
>サーバを安全にする</a>まで <directive module="mod_proxy"
>ProxyRequests</directive> は有効にしないでください。
オープンプロキシサーバはあなた自身のネットワークにとっても、
インターネット全体にとっても危険です。</p>
</note>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>ProxyRemote</name>
<description>特定のリクエストを扱う時に使われるリモートプロキシを指定する</description>
<syntax>ProxyRemote <var>match</var> <var>remote-server</var></syntax>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
<p>このディレクティブはこのプロキシに対するリモートプロキシを定義します。
<var>match</var> はリモートサーバがサポートする URL スキーム、
リモートサーバが使うはずの URL の一部分、サーバがすべての
リクエストに使われることを示す <code>*</code> のどれかになります。
<var>remote-server</var> はリモートサーバの部分 URL です。構文:</p>
<example>
<dfn>remote-server</dfn> =
<var>scheme</var>://<var>hostname</var>[:<var>port</var>]
</example>
<p><var>scheme</var> は実際上リモートサーバとの通信に使われるプロトコルを
決定します。このモジュールでは <code>http</code> だけがサポートされて
います。</p>
<example><title>例</title>
ProxyRemote http://goodguys.com/ http://mirrorguys.com:8000<br />
ProxyRemote * http://cleversite.com<br />
ProxyRemote ftp http://ftpproxy.mydomain.com:8080
</example>
<p>この例では、プロキシは FTP リクエストを別の HTTP リクエストで包んで
そのようなリクエストを扱える別のプロキシに転送します。</p>
<p>このオプションはリバースプロキシの設定もサポートします。
サーバが別のフォワードプロキシの後ろに隠されている場合でも
バックエンドウェブサーバをバーチャルホストの URL 空間に入れることが
できます。</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>ProxyRemoteMatch</name>
<description>正規表現でのマッチによるリクエストを扱うリモートプロキシの指定</description>
<syntax>ProxyRemoteMatch <var>regex</var> <var>remote-server</var></syntax>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
<p><directive>ProxyRemoteMatch</directive> は最初の引数がリクエストされた
URL にマッチする<glossary ref="regex">正規表現</glossary>であることを除けば <directive
module="mod_proxy">ProxyRemote</directive> ディレクティブと同じです。</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>ProxySet</name>
<description>Set various Proxy balancer or member parameters</description>
<contextlist><context>directory</context></contextlist>
<usage><p>Documentation not yet translated. Please see English version of document.</p></usage>
</directivesynopsis>
<directivesynopsis>
<name>ProxyStatus</name>
<description>Show Proxy LoadBalancer status in mod_status</description>
<contextlist><context>server config</context><context>virtual host</context></contextlist>
<usage><p>Documentation not yet translated. Please see English version of document.</p></usage>
</directivesynopsis>
<directivesynopsis>
<name>ProxyPass</name>
<description>リモートサーバをローカルサーバの URL 空間にマップする</description>
<syntax>ProxyPass [<var>path</var>] !|<var>url</var> [<var>key=value</var> <var>key=value</var> ...]]</syntax>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context>
</contextlist>
<usage>
<p>このディレクティブはリモートサーバをローカルサーバの名前空間に
マップできるようにします。ローカルサーバは通常の意味でのプロキシと
しては動作せず、リモートサーバのミラーとして振る舞います。
<var>path</var> はローカルの仮想パスの名前です。<var>url</var> は
リモートサーバの部分 URL になり、クエリー文字列を含むことはできません。</p>
<note type="warning"><directive>ProxyPass</directive> ディレクティブを
使っているときは <directive
module="mod_proxy">ProxyRequests</directive> ディレクティブは通常は
<strong>off</strong> に設定されているべきです。</note>
<p>ローカルサーバのアドレスが <code>http://example.com/</code> であると
します。すると、</p>
<example>
ProxyPass /mirror/foo/ http://backend.example.com/
</example>
<p>と設定すると <code>http://example.com/mirror/foo/bar</code> への
リクエストが内部的に <code>http://backend.example.com/bar</code> への
プロキシリクエストに変換されることになります。</p>
<p>サブディレクトリをリバースプロキシしたくないときに <code>!</code> は
役に立ちます。<em>例えば</em>、</p>
<example>
ProxyPass /mirror/foo/i !<br />
ProxyPass /mirror/foo http://backend.example.com
</example>
<p>は <code>/mirror/foo/i</code> を<em>除く</em>
<code>/mirror/foo</code> へのすべてのリクエストを
<code>backend.example.com</code> にプロキシします。</p>
<note><title>注</title>
<p>順番は重要です。一般的な <directive>ProxyPass</directive>
ディレクティブの<em>前に</em>
除外ディレクティブを置く必要があります。</p>
</note>
<p>2.1 の機能で、バックエンドサーバとの接続にプールされたコネクションを
使えるようになりました。<code>key=value</code> 形式のパラメータで
このコネクションプーリングの調整ができます。<code>Hard Maximum</code>
のデフォルト値は、有効になっている MPM でのプロセス当たりのスレッド数と
同じ数のコネクション数です。prefork MPM では通常は 1 で、worker MPM では
<directive>ThreadsPerChild</directive> で調整されます。</p>
<p><code>min</code> の設定で、バックエンドサーバとの間に何本のコネクションを
常時開くかが決まります。Soft Maximum <code>smax</code> の数に
達するまで必要に応じてコネクションは生成されます。<code>smax</code>
を超えた数のコネクションは、生存時間 <code>ttl</code> で切断されます。
バックエンドサーバと Hard Maximum <code>max</code> の数以上のコネクションを
生成することはありません。</p>
<example>
ProxyPass /example http://backend.example.com smax=5 max=20 ttl=120 retry=300
</example>
<table>
<tr><th>パラメータ</th>
<th>デフォルト値</th>
<th>説明</th></tr>
<tr><td>min</td>
<td>0</td>
<td>バックエンドサーバとの接続で
常に開いているコネクション数の最小値</td></tr>
<tr><td>max</td>
<td>1...n</td>
<td>バックエンドサーバとの接続数の Hard Maximum
<transnote>ハードリミット</transnote>。
デフォルト値は、使用している MPM のプロセスあたりのスレッド数になっています。
Prefork MPM では常に 1 で、Worker MPM では <directive>ThreadsPerChild</directive>
で調節できます。Hard Maximum 以上にバックエンドサーバとのコネクションを
生成することはありません。</td></tr>
<tr><td>smax</td>
<td>max</td>
<td>接続数の Soft Maximum <transnote>ソフトリミット</transnote>まで、
コネクションは必要に応じて生成されます。
<code>smax</code> を超えた数のコネクションは生存時間 <code>ttl</code>
で切断されます。
</td></tr>
<tr><td>ttl</td>
<td>-</td>
<td><code>smax</code> 数を超えた非活動状態のコネクションの生存時間を、
秒で指定します。この期間内に使用されなかったコネクションは、
全て閉じられます。
</td></tr>
<tr><td>timeout</td>
<td><directive>Timeout</directive></td>
<td>コネクションタイムアウトを秒で指定します。特に指定されなければ、
フリーなコネクションを取得できるまで待ちます。このディレクティブは
<code>max</code> パラメータと合わせて使うことで、バックエンドサーバとの
接続数を制御するのに使います。
</td></tr>
<tr><td>acquire</td>
<td>-</td>
<td>設定すると、コネクションプールからフリーのコネクションを取得するために
待機する待ち時間の最大値になります。フリーのコネクションがプールになかった場合は、
<code>SERVER_BUSY</code> ステータスがクライアントに返されます。
</td></tr>
<tr><td>keepalive</td>
<td>Off</td>
<td>バックエンドサーバと Apache の間にファイアーウォールがある場合には、
このパラメータを使ってください。ファイアウォールは往々にして、
非活動状態のコネクションを落とそうとします。
このフラグは OS に指示して、<code>KEEP_ALIVE</code> メッセージを非活動状態の
コネクションでも送るようにします (間隔は OS のグローバル設定に依存し、
通常は 120ms 間隔) 。これによってファイアウォールによってコネクションが
落とされることを防げます。keepalive を有効にするには、このプロパティを
<code>On</code> にしてください。
</td></tr>
<tr><td>retry</td>
<td>60</td>
<td>コネクションをプーリングするための、リトライのタイムアウトを秒で
指定します。バックエンドサーバへのコネクションプーリングが失敗した場合は、
タイムアウトの期間が過ぎるまで、そのサーバにリクエストをフォワードしません。
この機能を使うと、バックエンドサーバをメンテナンスのためにシャットダウンし、
後でオンラインに復帰させるといったことができます。
</td></tr>
<tr><td>loadfactor</td>
<td>1</td>
<td>ワーカーあたりの負荷係数です。BalancerMember で使います。
1 から 100 までの数字でそのワーカーに対する正規化された負荷率を指定します。
</td></tr>
<tr><td>route</td>
<td>-</td>
<td>ロードバランサで使った場合、ワーカーのルーティングをします。
ルートはセッション ID に付加された値になります。
</td></tr>
<tr><td>redirect</td>
<td>-</td>
<td>ワーカーのリダイレクション経路です。この値は通常は、
安全にクラスタからノードを取り去る設定を動的に入れるために使います。
セッション ID の無いリクエスト全てを指定した場合は、
この値と同じルーティングパラメータを持つ
BalancerMember にリダイレクトされます。
</td></tr>
</table>
<p>Proxy ディレクティブのスキームが <code>balancer://</code> になっている場合は、
バックエンドサーバと実際には通信しない仮想ワーカーが生成されます。
このワーカーは幾つかの "本物の" ワーカーの管理をつかさどります。
この場合パラメータは、この仮想ワーカーに対して設定されます。
</p>
<table>
<tr><th>パラメータ</th>
<th>デフォルト値</th>
<th>説明</th></tr>
<tr><td>lbmethod</td>
<td>-</td>
<td>Balancer のロードバランス方法。使用するロードバランスの
スケジューリング方法を選びます。処理したリクエストの数で重み付けする
<code>byrequests</code> か、転送量のバイト数で重み付けする
<code>bytraffic</code> を設定できます。デフォルトは
<code>byrequests</code> です。
</td></tr>
<tr><td>stickysession</td>
<td>-</td>
<td>バランサーのスティッキーセッション名です。通常はこの値は <code>JSESSIONID</code>
や <code>PHPSESSIONID</code> といったものになりますが、この値は
バックエンドアプリケーションのサポートするセッションに依存します。
</td></tr>
<tr><td>nofailover</td>
<td>Off</td>
<td><code>On</code> になっていると、ワーカーがエラーを起こしたり
無効になっている場合にセッションが切れます。
バックエンドサーバがセッションレプリケーションをサポートしていない場合は、
On にしてください。
</td></tr>
<tr><td>timeout</td>
<td>0</td>
<td>バランサーのタイムアウトを秒で指定します。
この値を設定すると、フリーのワーカーを取得するまでの最大待機時間になります。
デフォルトでは待機しません。
</td></tr>
<tr><td>maxattempts</td>
<td>1</td>
<td>フェイルオーバーを試みる最大の回数を指定します。
</td></tr>
</table>
<example>
ProxyPass /special-area http://special.example.com/ smax=5 max=10<br />
ProxyPass / balancer://mycluster stickysession=jsessionid nofailover=On<br />
<Proxy balancer://mycluster><br />
<indent>
BalancerMember http://1.2.3.4:8009<br />
BalancerMember http://1.2.3.5:8009 smax=10<br />
# Less powerful server, don't send as many requests there<br />
BalancerMember http://1.2.3.6:8009 smax=1 loadfactor=20<br />
</indent>
</Proxy>
</example>
<p><directive type="section" module="core"
>Location</directive> セクションの中で使われた場合、最初の引数は
省略され、ローカルディレクトリは <directive type="section" module="core"
>Location</directive> から取得されます。</p>
<p>より柔軟なリバースプロキシの設定が必要な場合は、<code>[P]</code>
フラグ付きの <directive module="mod_rewrite">RewriteRule</directive>
ディレクティブを参照してください。</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>ProxyPassInterpolateEnv</name>
<description>Enable Environment Variable interpolation in Reverse Proxy configurations</description>
<contextlist><context>server config</context><context>virtual host</context><context>directory</context></contextlist>
<usage><p>Documentation not yet translated. Please see English version of document.</p></usage>
</directivesynopsis>
<directivesynopsis>
<name>ProxyPassMatch</name>
<description>Maps remote servers into the local server URL-space using regular expressions</description>
<contextlist><context>server config</context><context>virtual host</context><context>directory</context></contextlist>
<usage><p>Documentation not yet translated. Please see English version of document.</p></usage>
</directivesynopsis>
<directivesynopsis>
<name>ProxyPassReverse</name>
<description>リバースプロキシされたサーバから送られた HTTP 応答ヘッダの
URL を調整する</description>
<syntax>ProxyPassReverse [<var>path</var>] <var>url</var></syntax>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context>
</contextlist>
<usage>
<p>このディレクティブは Apache に HTTP リダイレクト応答の
<code>Location</code>, <code>Content-Location</code>, <code>URI</code>
ヘッダの調整をさせます。これは、Apache がリバースプロキシとして使われている
ときに、リバースプロキシを通さないでアクセスすることを防ぐために
重要です。これによりバックエンドサーバの HTTP リダイレクトが
リバースプロキシとバックエンドの間で扱われるようになります。</p>
<p>ディレクティブで明示されている HTTP 応答ヘッダのみが書き換えられます。
Apache は他の応答ヘッダを書き換えたり、HTML ページの中の URL 参照を
書き換えたりすることはありません。HTML の中を見て、URL 参照を書き換える
モジュールに Nick Kew さんの <a
href="http://apache.webthing.com/mod_proxy_html/"
>mod_proxy_html</a> があります。</p>
<p><var>path</var> はローカル仮想パスの名前です。<var>url</var> は
リモートサーバの部分 URL です。これらは <directive module="mod_proxy"
>ProxyPass</directive> ディレクティブと同様です。</p>
<p>例えば、ローカルサーバのアドレスが <code>http://example.com/</code>
だとします。すると</p>
<example>
ProxyPass /mirror/foo/ http://backend.example.com/<br />
ProxyPassReverse /mirror/foo/ http://backend.example.com/<br />
ProxyPassReverseCookieDomain backend.example.com public.example.com<br />
ProxyPassReverseCookiePath / /mirror/foo/
</example>
<p>という設定をすると、<code>http://example.com/mirror/foo/bar</code>
へのローカルリクエストが <code>http://backend.example.com/bar</code>
へのプロキシリクエストに内部でリダイレクトされるだけではありません
(これは <code>ProxyPass</code> の機能です)。<code>backend.example.com</code>
が送るリダイレクトの面倒もみます。<code>http://backend.example.com/bar</code>
が <code>http://backend.example.com/quux</code> にリダイレクトされたとき、
Apache は HTTP リダイレクト応答をクライアントに送る前に、
<code>http://example.com/mirror/foo/quux</code> に変更します。
URL を構成するのに使われるホスト名は <directive
module="core">UseCanonicalName</directive> の設定に応じて選択されることに
注意してください。</p>
<p><directive>ProxyPassReverse</directive> ディレクティブは
対応する <directive module="mod_proxy"
>ProxyPass</directive> ディレクティブには依存しないため、
<module>mod_rewrite</module> のプロキシ通過機能
(<code>RewriteRule ... [P]</code>) と併せて使用することができます。</p>
<p><directive type="section" module="core"
>Location</directive> セクションの中で使われた場合は、
最初の引数は省略され、ローカルディレクトリは <directive
type="section" module="core">Location</directive> から取得されます。</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>ProxyPassReverseCookieDomain</name>
<description>リバースプロキシサーバからの Set-Cookie ヘッダの Domain 文字列を
調整する</description>
<syntax>ProxyPassReverseCookieDomain <var>internal-domain</var> <var>public-domain</var></syntax>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context>
</contextlist>
<usage>
<p>使用法は基本的に
<directive module="mod_proxy">ProxyPassReverse</directive> と同じですが、
ヘッダの URL の代わりに <code>Set-Cookie</code> ヘッダの
<code>domain</code> 文字列を書き換えます。</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>ProxyPassReverseCookiePath</name>
<description>Reverse プロキシサーバからの Set-Cookie ヘッダの Path 文字列を
調整する</description>
<syntax>ProxyPassReverseCookiePath <var>internal-path</var> <var>public-path</var></syntax>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context>
</contextlist>
<usage>
<p>使用法は基本的に
<directive module="mod_proxy">ProxyPassReverse</directive> と同じですが、
ヘッダの URL の代わりに <code>Set-Cookie</code> ヘッダの
<code>path</code> 文字列を書き換えます。</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>AllowCONNECT</name>
<description>プロキシを経由して、どのポートに <code>CONNECT</code>
できるかを指定する</description>
<syntax>AllowCONNECT <var>port</var> [<var>port</var>] ...</syntax>
<default>AllowCONNECT 443 563</default>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
<p><directive>AllowCONNECT</directive> はプロキシの <code>CONNECT</code>
メソッドが接続を許可するポート番号のリストを指定します。
今日のブラウザは、<code>https</code> コネクションが要求されていて、
HTTP 上でのプロキシによるトンネリングができるときに、
このメソッドを使います。</p>
<p>デフォルトの設定では、https のデフォルトポート (<code>443</code>) と
デフォルトの snews ポート (<code>563</code>) が有効になっています。
このデフォルトを上書きして、リストに記載したポートにのみ接続を許可したい場合、
<directive>AllowCONNECT</directive> ディレクティブを使用します。</p>
<p><code>CONNECT</code> を使用するには、<module>mod_proxy_connect</module>
がサーバに組み込まれていなければならないことに注意してください。</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>ProxyBlock</name>
<description>プロキシ接続を禁止する語句、ホスト名、ドメインを指定する</description>
<syntax>ProxyBlock *|<var>word</var>|<var>host</var>|<var>domain</var>
[<var>word</var>|<var>host</var>|<var>domain</var>] ...</syntax>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
<p><directive>ProxyBlock</directive> ディレクティブは空白で区切られた
語句、ホスト名、ドメインのリストを指定します。サイト名にその語句、ホスト名、
ドメインを含むサイトへの HTTP、HTTPS、FTP によるドキュメントのリクエストは
プロキシサーバにより<em>ブロックされます</em>。プロキシモジュールは
起動時にホスト名と思しき項目の IP アドレスを調べ、後のテストのために
キャッシュします。これにより、サーバの起動が少し遅くなるかもしれません。</p>
<example><title>Example</title>
ProxyBlock joes-garage.com some-host.co.uk rocky.wotsamattau.edu
</example>
<p><code>rocky.wotsamattau.edu</code> が IP アドレスで参照されたときでも
マッチします。</p>
<p><code>wotsamattau.edu</code> のマッチには <code>wotsamattau</code>
だけでも十分です。</p>
<example>
ProxyBlock *
</example>
<p>はすべてのサイトへの接続をブロックすることに注意してください。</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>ProxyReceiveBufferSize</name>
<description>プロキシされる HTTP と FTP 接続のためのネットワークバッファサイズ</description>
<syntax>ProxyReceiveBufferSize <var>bytes</var></syntax>
<default>ProxyReceiveBufferSize 0</default>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
<p><directive>ProxyReceiveBufferSize</directive> ディレクティブは
スループットを上げるために明示的に (TCP/IP) ネットワークバッファのサイズを
設定します。値は <code>512</code> 以上か、システムのデフォルトのバッファ
サイズを意味する <code>0</code> でなければなりません。</p>
<example><title>例</title>
ProxyReceiveBufferSize 2048
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>ProxyIOBufferSize</name>
<description>内部データスループットバッファのサイズを決定する</description>
<syntax>ProxyIOBufferSize <var>bytes</var></syntax>
<default>ProxyIOBufferSize 8192</default>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
<p><directive>ProxyIOBufferSize</directive> ディレクティブは入力と
出力用の一時メモリとして使われる内部バッファのサイズを調整します。
サイズは <code>8192</code> 以下でなければなりません。</p>
<p>ほとんどすべての場合、この値を変更する理由はありません。</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>ProxyMaxForwards</name>
<description>リクエストがフォワードされるプロキシの最大数</description>
<syntax>ProxyMaxForwards <var>number</var></syntax>
<default>ProxyMaxForwards 10</default>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<compatibility>Apache 2.0 以降で使用可能</compatibility>
<usage>
<p><directive>ProxyMaxForwards</directive> ディレクティブは
リクエストに <code>Max-Forwards</code> ヘッダが指定されていない場合に
リクエストが通過可能なプロキシの最大数を設定します。これは
プロキシの無限ループや DoS 攻撃を防ぐために設定されています。</p>
<example><title>例</title>
ProxyMaxForwards 15
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>NoProxy</name>
<description>直接接続する ホスト、ドメイン、ネットワーク</description>
<syntax>NoProxy <var>host</var> [<var>host</var>] ...</syntax>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
<p>このディレクティブはイントラネット中の Apache プロキシサーバにのみ
有用です。<directive>NoProxy</directive> ディレクティブは空白区切りで、
サブネット、IP アドレス、ホスト、ドメインのリストを指定します。
これらのどれかにマッチするホストへのリクエストは <directive
module="mod_proxy">ProxyRemote</directive> で設定されたプロキシサーバに
フォワードされず、直接処理されます。</p>
<example><title>例</title>
ProxyRemote * http://firewall.mycompany.com:81<br />
NoProxy .mycompany.com 192.168.112.0/21
</example>
<p><directive>NoProxy</directive> ディレクティブの <var>host</var> 引数は
以下の種類のどれかです:</p>
<dl>
<!-- ===================== Domain ======================= -->
<dt><var><a name="domain" id="domain">Domain</a></var></dt>
<dd>
<p><dfn>Domain</dfn> は先頭にピリオドの着いた部分 DNS ドメイン名です。
同一 DNS ドメイン及びゾーン (<em>すなわち</em>、ホスト名の末尾がすべて
<var>Domain</var> で終わっているということ) に属するホストのリストを
表します)。</p>
<example><title>例</title>
.com .apache.org.
</example>
<p><var>Domain</var> を <a href="#hostname"
>Hostname</a> と区別するために (意味的にも構文的にも。DNS ドメインも
DNS の A レコードを持つことができるのです!)、<var>Domain</var> は
常にピリオドで始まります。</p>
<note><title>注</title>
<p>ドメイン名の比較は大文字小文字を区別せずに行なわれ、<var>Domain</var>
は常に DNS ツリーのルートから始まるものとみなされます。ですから、
次の二つのドメイン <code>.MyDomain.com</code> と
<code>.mydomain.com.</code> (最後のピリオドに注目) は同一であると
みなされます。ドメインの比較は DNS ルックアップなしで行なわれるため、
サブネットの比較よりもずっと効率的です。</p>
</note></dd>
<!-- ===================== SubNet ======================= -->
<dt><var><a name="subnet" id="subnet">SubNet</a></var></dt>
<dd>
<p><dfn>SubNet</dfn> は数値形式 (ドットで区切られた四つの数字) の
部分インターネットアドレスです。後にスラッシュと <var>Subnet</var>
の意味のあるビット数を指定するネットマスクとを続けることができます。
共通のネットワークインタフェースを使って到達することのできるサブネットを
表すために使われます。明示的にネットマスクを指定しない場合は
最後の省略された (もしくは値が 0 の) 数字がマスクを指定します。
(この場合は、ネットマスクは 8 ビット単位でしか指定できません。)
例:</p>
<dl>
<dt><code>192.168</code> もしくは <code>192.168.0.0</code></dt>
<dd>サブネット 192.168.0.0 と暗黙の 16 ビット有効なネットマスク
(<code>255.255.0.0</code> というネットマスクの形式で使われることも
あります)</dd>
<dt><code>192.168.112.0/21</code></dt>
<dd>サブネット<code>192.168.112.0/21</code> と 21 ビット有効な
ネットマスク (<code>255.255.248.0</code> という形式で使われることも
あります)</dd>
</dl>
<p>特別な場合に、32 ビット有効な <em>SubNet</em> は
<var><a href="#ipadr">IPAddr</a></var> と同等で、
0 ビット有効な <var>SubNet</var> (<em>例えば</em>、0.0.0.0/0) は
すべての IP アドレスにマッチする定数 <var>_Default_</var> と同じです。</p>
</dd>
<!-- ===================== IPAddr ======================= -->
<dt><var><a name="ipaddr" id="ipaddr">IPAddr</a></var></dt>
<dd>
<p><dfn>IPAddr</dfn> は数値形式 (ドットで区切られた四つの数字) の
完全インターネットアドレスです。通常はこのアドレスはホストを
表しますが、必ずしもアドレスに対応する DNS ドメイン名があるわけでは
ありません。</p>
<example><title>例</title>
192.168.123.7
</example>
<note><title>注</title>
<p><var>IPAddr</var> は DNS システムにより解決される必要がないので、
apache の性能が向上するかもしれません。</p>
</note></dd>
<!-- ===================== Hostname ======================= -->
<dt><var><a name="hostname" id="hostname">Hostname</a></var></dt>
<dd>
<p><dfn>Hostname</dfn> は DNS ドメインサービスにより一つもしくは
複数の <var><a href="#ipaddr">IPAddr</a></var> に解決可能な
完全な DNS ドメイン名です。これは (<var><a href="#domain">Domain</a></var>
と違って、説明は上記を参照) 論理的なホストを表し、少くとも一つの
<var><a href="#ipaddr">IPAddr</a></var> (もしくは違う
<var><a href="#ipaddr">IPAddr</a></var> のホストのリスト) に解決
されなければなりません)。</p>
<example><title>例</title>
prep.ai.mit.edu<br />
www.apache.org
</example>
<note><title>注</title>
<p>多くの場合、<var>Hostname</var> の代わりに <var><a
href="#ipaddr">IPAddr</a></var> を指定した方が、DNS ルックアップを
避けることができるため、効率が良くなります。Apache の名前解決は
ネームサーバへの接続が遅い PPP 上の場合などにかなり時間を取られる
ことがあります。</p>
<p><var>Hostname</var> の比較は大文字小文字を区別せずに行なわれ、
<var>Hostname</var> は常に DNS ツリーのルートから始まるものとみなされます。
ですから、二つのドメイン <code>WWW.MyDomain.com</code> と
<code>www.mydomain.com.</code> (最後のピリオドに注目) は同一であると
みなされます。</p>
</note></dd>
</dl>
</usage>
<seealso><a href="../dns-caveats.html">DNS に関する問題</a></seealso>
</directivesynopsis>
<directivesynopsis>
<name>ProxyTimeout</name>
<description>プロキシされたリクエストのネットワークタイムアウト</description>
<syntax>ProxyTimeout <var>seconds</var></syntax>
<default>ProxyTimeout 300</default>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<compatibility>Apache 2.0.31 以降で使用可能</compatibility>
<usage>
<p>このディレクティブはユーザがプロキシリクエストのタイムアウトを
指定できるようにします。これはハングしてしまう遅い、もしくは挙動の
怪しいサーバがあり、サーバがデータを返すまでひたすら待ち続けるよりも
タイムアウトを返してより緩やかに<transnote>graceful に</transnote>
失敗させたい場合に役に立ちます。</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>ProxyDomain</name>
<description>プロキシされたリクエストのデフォルトのドメイン名</description>
<syntax>ProxyDomain <var>Domain</var></syntax>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
<p>このディレクティブはイントラネット内の Apache プロキシサーバにのみ
有用です。<directive>ProxyDomain</directive> ディレクティブは
apache プロキシサーバが属するデフォルトのドメインを指定します。
ドメイン名の無いリクエストを受けた場合、設定された <var>Domain</var>
が追加された同じホストへのリダイレクト応答が返されます。</p>
<example><title>例</title>
ProxyRemote * http://firewall.mycompany.com:81<br />
NoProxy .mycompany.com 192.168.112.0/21<br />
ProxyDomain .mycompany.com
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>ProxyVia</name>
<description>プロキシされたリクエストの <code>Via</code> HTTP 応答ヘッダ
により提供される情報</description>
<syntax>ProxyVia On|Off|Full|Block</syntax>
<default>ProxyVia Off</default>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
<p>このディレクティブはプロキシの <code>Via:</code> HTTP ヘッダの使用を
制御します。想定されている使い方は、プロキシサーバがいくつも繋がっているときに
プロキシリクエストの流れを制御することです。<code>Via:</code> ヘッダ行の
説明は <a
href="http://www.ietf.org/rfc/rfc2616.txt">RFC 2616</a> (HTTP/1.1)
の 14.45 節を読んでください。</p>
<ul>
<li>デフォルトの <code>Off</code> に設定されていると、特別な処理は
行なわれません。リクエストやリプライに <code>Via:</code> ヘッダがあれば、
変更されずにそのまま渡します。</li>
<li><code>On</code> に設定されていれば、各リクエストとリプライに
<code>Via:</code> 行が追加されます。</li>
<li><code>Full</code> に設定されていれば、<code>Via:</code> ヘッダは
コメント部分に Apache サーバのバージョンも含むようになります。</li>
<li><code>Block</code> に設定されていれば、すべてのプロキシリクエストから
<code>Via:</code> ヘッダが取り除かれます。新たに <code>Via:</code> が
生成されることはありません。</li>
</ul>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>ProxyErrorOverride</name>
<description>プロキシされたコンテンツのエラーページを上書きする</description>
<syntax>ProxyErrorOverride On|Off</syntax>
<default>ProxyErrorOverride Off</default>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<compatibility>バージョン 2.0 以降で使用可能</compatibility>
<usage>
<p>このディレクティブはリバースプロキシを使用していて、
エンドユーザに送られるエラーページの外見を共通のものにしたいときに
有用です。このディレクティブは (<module>mod_include</module> の SSI によって)
インクルードされたファイルがエラーコードを取得して、正しく動作を
するようにもします (デフォルトの動作は、プロキシされたサーバの
エラーページの表示で、このディレクティブを有効にすると SSI のエラー
メッセージを表示します)。</p>
</usage>
</directivesynopsis>
</modulesynopsis>
|