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 <igor@sysoev.ru> 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. <reallfqq-nginx@yahoo.fr> 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 <mdounin@mdounin.ru> 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
>>> nginx@nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx
>>>
>>
>>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
>
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx