That's exactly what I tried first, and if there are multiple servers listening to same ports, I get the following error: nginx: [emerg] duplicate listen options for [::]:80 in /etc/nginx/conf.d/***.conf:3 See follow-up messages or (through the forum archive on this subject): http://forum.nginx.org/read.php?2,238147,238152#msg-238152
I have the feeling we entered a loop back to the top of the subject... Let me summarize : *Attempt #1* listen 80; listen [::]:80 ipv6only=on; Only works if a *single* server contains those directives. Produces error 'nginx: [emerg] duplicate listen options for [::]:80 in /etc/nginx/conf.d/***.conf:3' if several servers use them to listen to the same ports. *Attempt #2* listen [::]:80; 'Wrong approach' said Maxim, since it won't work in 1.4 stable due to changes in the 1.3 dev branch. However, in 1.2, that's the only working way I have to decide on per-server level which protocol and ports they need to listen to. I'm stuck. --- *B. R.* On Sat, Apr 6, 2013 at 11:23 AM, Igor Sysoev <[email protected]> wrote: > server { > listen 80; > listen [::]:80 ipv6only=on; > server_name one; > ... > } > > server { > listen 443 ssl; > listen [::]:443 ssl ipv6only=on; > server_name one; > ... > } > > > -- > Igor Sysoev > http://nginx.com/services.html > > On Apr 6, 2013, at 19:01 , B.R. wrote: > > Add-on: > > Besides, as I explained earlier, having generic 'listen' directives > implies some difficulties. > > For example, I am using 2 virtual servers to serve content for the same > server_name, one listening on port 80, the other on port 443, allowing me > to serve cotnent for HTTP and HTTPS in different fashions. > Using generic 'listen' directive breaks that system and I'm stuck. > > What would be an acceptable solution? > Thanks, > --- > *B. R.* > > > On Sat, Apr 6, 2013 at 10:52 AM, B.R. <[email protected]> wrote: > >> But as I noticed earlier, these configuration directives conflict with >> each other across multiple virtual servers... >> That's a huge step backwards. >> >> H >> aving to specify them only once across every configuration file is >> counter-intuitive. >> Why isn't nginx able to summarize all the needs for listening sockets >> across configuraiton files before attempting to open them? >> Having to define those listening directives in a 'generic default server' >> is awkward and looks ugly. >> >> --- >> *B. R.* >> >> >> On Sat, Apr 6, 2013 at 6:39 AM, Maxim Dounin <[email protected]> wrote: >> >>> Hello! >>> >>> On Sat, Apr 06, 2013 at 02:25:54AM -0400, B.R. wrote: >>> >>> > Hello, >>> > >>> > It seems I solved the problem... >>> > It was indeed by reading a little more carefully the doc >>> > http://wiki.nginx.org/HttpCoreModule#listen, thanks @Lukas! ;o) >>> > >>> > The '*:80' syntax is used for IPv4 listening, I don't understand why it >>> > works as-is for you Ted. Maybe Maxim will be of a better help on that >>> case. >>> > >>> > It is said that the IPv6 syntax will make Nginx listen for the 6to4 IP >>> > address syntax, making the websites reachable through IPv4, even if no >>> > specific IPv4 binding exist for the listening sockets. >>> > Using: >>> > listen [::]:80; >>> > >>> > I have: >>> > $ sudo ss -lnp|grep nginx >>> > 0 128 :::80 >>> > :::* users:(("nginx",***,11),("nginx",***,11)) >>> > 0 128 :::443 >>> > :::* users:(("nginx",***,12),("nginx",***,12)) >>> > >>> > You shall *not* have 2 'listen' directive if you did not separate you >>> IPv6 >>> > and IPv4 stacks (with the sysctl net.ipv6.bindv6only directive set to >>> 1). >>> >>> This is wrong aproach and it will no longer work for you after >>> 1.3.x upgrade. As I already suggested, use >>> >>> listen 80; >>> listen [::]:80 ipv6only=on; >>> >>> instead as a portable solution, which doesn't depend on a system >>> configuration. (In 1.3.x, the "ipv6only=on" part can be removed >>> as it's now the default.) >>> >>> -- >>> Maxim Dounin >>> http://nginx.org/en/donation.html >>> >>> _______________________________________________ >>> nginx mailing list >>> [email protected] >>> http://mailman.nginx.org/mailman/listinfo/nginx >>> >> >> > _______________________________________________ > nginx mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx > > > > _______________________________________________ > nginx mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx >
_______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
