I can confirm I see the same thing.
If you use set_real_ip_from, real_ip_header, etc then it wipes out the
$server_port value.
Is there any work around to this?
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,261668,272576#msg-272576
___
ng
depending on the version you may want to look
for /etc/nginx/conf.d/default.conf, when i have been building servers (i
use salt for configuration management) i have in my state file that
includes
file.absent:
- /etc/nginx/conf.d/default.conf
which will ensure the file does not exist immediately
On Wed, Feb 22, 2017 at 06:29:56AM +0100, Filip Francis wrote:
Hi there,
I haven't tested any of this, but...
> I am trying to set-up a reverse proxy with nginx so that based on
> the server_name it goes to the correct backend.
That should be straightforward; and it looks to me like you almost
Hi,
I'm have following configuration.
nginx 1.10.3 installed on ubuntu 16.04
one upstream
upstream backend {
server app01.local.net:81;
server app02.local.net:81;
server app03.local.net:81;
}
one vhost that dose proxy_pass http://backend;
i also have a old nginx setup that was done
On Wed, Feb 22, 2017 at 03:55:48AM +0200, Litichevskij Vova wrote:
Hi there,
> Or in this way with named location:
>
> server {
>
> location / {
> auth_request @auth;
> proxy_pass http://protected.resource;
> }
>
> location @auth {
> proxy_pass http://extern
Hello All,
I have another "bind() to 0.0.0.0:80 failed (98: Address already in use)"
issue.
I am working on a minimal system including nginx only. System startup time,
and readiness time are important points. Whilte testing I figured out
sometime system boots up within 500ms and sometimes it tak
I suggest you proxy traffic to an upstream group, and then use
failure/timeout parameters there with proper tuning to retry requests on
the second upstream in case the first in the list fails.
It will have an overhead if the 1st entry of the upstream group is invalid
on initial connection, but hop
Thanks again for detailed reply. Yeah it would have been good to have this
feature in nginx upstream module.
Its an important feature, will try out your suggestions and will share.
Thanks a lot for sharing inputs!
Cheers,
Kaustubh
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,27244
No they cannot be the same (sadly) because i dont't know how the upstream is
serving the content. Think of a situation where i am not in control of the
upstream backends and they may change from http to https over time.
Von: nginx im Auftrag von Cox, Eric S
Ge
Hi Francis
You're right I have overseen the ^~ for the location.
So for others, the solution to "force" the location directives is..
location ^~ /thumbs/embedded {
add_header X-Served-By "IDENT1";
add_header Cache-Control public;
add_header Pragma 'public';
add_header X-Cache-Status $upstream_c
If you are SSL on the frontend (server directive) why would you want to proxy
between ssl/non-ssl on the upstreams? Can they not be the same? I don't get
what you are trying to solve?
From: nginx [mailto:nginx-boun...@nginx.org] On Behalf Of Kilian Ries
Sent: Wednesday, February 22, 2017 9:55 AM
Hi,
i'm trying to setup two Nginx upstreams (one with HTTP and one with HTTPS) and
the proxy_pass module should decide which of the upstreams is serving "valid"
content.
The config should look like this:
upstream proxy_backend {
server xxx.xx.188.53;
server xxx.xx.188.53:4
On Tue, Feb 21, 2017 at 07:40:23PM -0700, Captain Wiggum wrote:
Hi there,
> The html uses image maps, such as:
> html v1 style:
> or newer css style:
>
> Neither seem to work with my nginx-1.10.1 on Fedora (really Amazon Linux).
Can you see which part is failing?
As I understand it, client-s
13 matches
Mail list logo
