now I understand the duplicate listen ports configured in the http block can be
used to implement virtual hosts.
but what's the purpose to allow this in the stream block? in my practise (with
1.9.15.1), nginx will randomly select a backend to serve the tcp/udp request
which seems useless.
b.t.w, I also tried with 1.11.x today, looks like configuring duplicate listen
ports in stream block is forbidden.
BR,
Joe
原始邮件
发件人： ＜[email protected]＞
收件人： ＜[email protected]＞
日 期 ：2017年02月13日 20:00
主 题 ：nginx Digest, Vol 88, Issue 18
Send nginx mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.nginx.org/mailman/listinfo/nginx
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of nginx digest..."
Today's Topics:
1. RE: having nginx listen the same port more than once
(Reinis Rozitis)
2. Apache to nginx (Daniel)
3. Re: having nginx listen the same port more than once
(Igor A. Ippolitov)
----------------------------------------------------------------------
Message: 1
Date: Mon, 13 Feb 2017 09:13:36 +0200
From: "Reinis Rozitis" ＜[email protected]＞
To: ＜[email protected]＞
Subject: RE: having nginx listen the same port more than once
Message-ID: ＜[email protected]＞
Content-Type: text/plain charset="UTF-8"
＞ I observe that the nginx runs with no error if there are duplicate listen
ports configured in the http server block or stream server block.
is this behavior as expected?
That is how every webserver capable of name based virtual hosts works.
So yes it's normal and expected.
＞ and if a request comes at such a port, which server would serve this request,
by radomly or round-robin?
http://nginx.org/en/docs/http/request_processing.html
rr
------------------------------
Message: 2
Date: Mon, 13 Feb 2017 10:23:44 +0100
From: Daniel ＜[email protected]＞
To: [email protected]
Subject: Apache to nginx
Message-ID: ＜[email protected]＞
Content-Type: text/plain charset="us-ascii"
Hi,
i create a vhost confuguration for a vhost but i ma not able to access /vakanz
for exmaple.
I got a 404 error on the access logs.
I Tried already with rewrite rules and i also tried with locations, no matter
what i do, nothing works.
Anyone has an idea what can i do?
Cheers
Daniel
server {
listen 80
root /var/www/vhosts/reisen/sbo/current/web
rewrite ^/static/(.*) /var/www/vhosts/reisen/fe/static/$1 last
rewrite ^/hrouter.js /var/www/vhosts/reisen/fe/index.php last
rewrite ^/router.js /var/www/vhosts/reisen/fe/index.php last
rewrite
^/(vakanz|vrij|ajax|boek|buchen){0}nbsp/var/www/vhosts/reisen/fe/index.php last
rewrite ^/(vakanz|vrij|ajax|boek|buchen)/.* /var/www/vhosts/reisen/fe/index.php
last
rewrite ^/himage/.* /var/www/vhosts/reisen/fe/index.php last
rewrite ^/image/.* /var/www/vhosts/reisen/fe/index.php last
rewrite ^/images/.* /var/www/vhosts/reisen/fe/index.php last
rewrite ^/nur-flug{0}nbsp/flight/destination permanent
set $my_https "off"
if ($http_x_forwarded_proto = "https") {
set $my_https "on"
}
server_name preprod.reisen.de
location / {
index app.php
add_header Access-Control-Allow-Headers "Origin, X-Requested-With,
Content-Type, Accept"
add_header Access-Control-Allow-Origin "*"
if (-f $request_filename) {
break
}
try_files $uri @rewriteapp
}
location @rewriteapp {
if ( $request_filename !~ opcache\.php ){
rewrite ^(.*){0}nbsp/app.php/$1 last
}
}
#rewrite
^/(vakanz|vrij|ajax|boek|buchen){0}nbsp/var/www/vhosts/reisen/fe/index.php last
#rewrite ^/(vakanz|vrij|ajax|boek|buchen)/.*
/var/www/vhosts/reisen/fe/index.php last
# location /vakanz {
# alias /var/www/vhosts/reisen/fe/
# }
location ~* .js$
{add_header Service-Worker-Allowed "/"
}
location ~ ^/app\.php/_apilogger(/|$) {
fastcgi_pass unix:/var/run/php/php7.0-fpm.sock
fastcgi_split_path_info ^(.+\.php)(/.*)$
include fastcgi_params
fastcgi_param SCRIPT_NAME $fastcgi_script_name
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name
fastcgi_param PATH_INFO $fastcgi_path_info
fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info
fastcgi_param HTTPS $my_https
fastcgi_param SYMFONY__CMS__ENABLED false
fastcgi_param CMS_ENABLED false
fastcgi_buffer_size 128k
fastcgi_buffers 4 256k
fastcgi_busy_buffers_size 256k
add_header Access-Control-Allow-Headers "Origin, X-Requested-With,
Content-Type, Accept"
add_header Access-Control-Allow-Origin "*"
# Prevents URIs that include the front controller. This will 404:
# http://domain.tld/app.php/some-path
# Remove the internal directive to allow URIs like this
internal
}
location ~ ^/proxy\.php(\?|/|$) {
fastcgi_pass unix:/var/run/php/php7.0-fpm.sock
fastcgi_split_path_info ^(.+\.php)(.*)$
include fastcgi_params
fastcgi_param SCRIPT_NAME $fastcgi_script_name
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name
fastcgi_param PATH_INFO $fastcgi_path_info
fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info
fastcgi_param HTTPS $my_https
fastcgi_param SYMFONY__CMS__ENABLED false
fastcgi_param CMS_ENABLED false
fastcgi_buffer_size 128k
fastcgi_buffers 4 256k
fastcgi_busy_buffers_size 256k
add_header Access-Control-Allow-Headers "Origin, X-Requested-With,
Content-Type, Accept"
add_header Access-Control-Allow-Origin "*"
# Prevents URIs that include the front controller. This will 404:
# http://domain.tld/app.php/some-path
# Remove the internal directive to allow URIs like this
#internal
}
location ~ ^/app\.php(/|$) {
fastcgi_pass unix:/var/run/php/php7.0-fpm.sock
fastcgi_split_path_info ^(.+\.php)(/.*)$
include fastcgi_params
fastcgi_param SCRIPT_NAME $fastcgi_script_name
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name
fastcgi_param PATH_INFO $fastcgi_path_info
fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info
fastcgi_param HTTPS $my_https
fastcgi_param SYMFONY__CMS__ENABLED false
fastcgi_param CMS_ENABLED false
fastcgi_buffer_size 128k
fastcgi_buffers 4 256k
fastcgi_busy_buffers_size 256k
add_header Access-Control-Allow-Headers "Origin, X-Requested-With,
Content-Type, Accept"
add_header Access-Control-Allow-Origin "*"
# Prevents URIs that include the front controller. This will 404:
# http://domain.tld/app.php/some-path
# Remove the internal directive to allow URIs like this
internal
}
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
＜http://mailman.nginx.org/pipermail/nginx/attachments/20170213/b191c527/attachment-0001.html＞
------------------------------
Message: 3
Date: Mon, 13 Feb 2017 14:42:22 +0300
From: "Igor A. Ippolitov" ＜[email protected]＞
To: [email protected]
Subject: Re: having nginx listen the same port more than once
Message-ID: ＜[email protected]＞
Content-Type: text/plain charset=windows-1252 format=flowed
Assuming a configuration with multiple similar 'listen' and
'server_name' statements, only the first one will work:
＞ server {
＞ listen 9090
＞ return 404
＞ server_name example.com
＞ }
＞ server {
＞ listen 9090
＞ return 403
＞ server_name example.com
＞ }
＞ server {
＞ listen 9090
＞ return 400
＞ server_name example.com
＞ }
＞ nginx: [warn] conflicting server name "example.com" on 0.0.0.0:9090,
＞ ignored
＞ nginx: [warn] conflicting server name "example.com" on 0.0.0.0:9090,
＞ ignored
Afaik, the only reply you would be able to get from such configuration
is '404'
On 13.02.2017 10:13, Reinis Rozitis wrote:
＞＞ I observe that the nginx runs with no error if there are duplicate listen
ports configured in the http server block or stream server block.
＞ is this behavior as expected?
＞
＞ That is how every webserver capable of name based virtual hosts works.
＞ So yes it's normal and expected.
＞
＞＞ and if a request comes at such a port, which server would serve this
request, by radomly or round-robin?
＞ http://nginx.org/en/docs/http/request_processing.html
＞
＞ rr
＞
＞ _______________________________________________
＞ nginx mailing list
＞ [email protected]
＞ http://mailman.nginx.org/mailman/listinfo/nginx
------------------------------
Subject: Digest Footer
_______________________________________________
nginx mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx
------------------------------
End of nginx Digest, Vol 88, Issue 18
*************************************_______________________________________________
nginx mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx
