Connection timeout from work, working anywhere else

Hello,

nginx is the HTTP server that is provided with my home automation
software,
jeedom. It is installed on my Raspberry Pi2.
Everyting is working fine, I can connect from my internal network and
from
outside.

But, when connecting from work, I get an error (navigator displays and
certificate issue …).

I had a lool to the logs and here is the corresponding entry in
/usr/share/nginx/www/jeedom/log/nginx.error:
2015/04/16 18:38:27 [error] 2151#0: *38577 upstream timed out (110:
Connection timed out) while reading upstream, client: 109.99.99.99,
server:
, request: “GET
/socket.io/?EIO=3&transport=websocket&sid=qY83EqT2TTpBpiTzAAIn
HTTP/1.1”,
upstream:
http://127.0.0.1:8070/socket.io/?EIO=3&transport=websocket&sid=qY83EqT2TTpBpiTzAAIn”,
host: “truc:4321”
2015/04/16 18:42:05 [error] 2150#0: *39108 upstream prematurely closed
connection while reading response header from upstream, client:
109.99.99.99, server: , request: “GET
/socket.io/?EIO=3&transport=polling&t=1429202405657-73&sid=lxHkscjGEw5l1p2YAAI8
HTTP/1.1”, upstream:
http://127.0.0.1:8070/socket.io/?EIO=3&transport=polling&t=1429202405657-73&sid=lxHkscjGEw5l1p2YAAI8”,
host: “truc:4321”, referrer:
https://truc:4321/jeedom/index.php?v=d&p=history

Of course 109.99.99.99 is my remote IP and “truc:4321” my domain name /
port
!

I am not sure this only log may help, but many thanks if you were kind
enough to provide me some help to understand and fix my issue. I can do
some
more tests and provide other logs, just let me know what I should do.

Thanks !

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,258187,258187#msg-258187

Short update, as I am still struggling with this problem: Same issue for
HTTP, if I route an external port to nginx on my raspberry. But if I
route
to another HTTP server, everything works fine from my work office. So
this
must have something to do with nginx, but I have absolutely no idea
where to
have a look and what to do. Any help would be very appreciated !

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,258187,258289#msg-258289

Try it with:
sendfile on;
tcp_nodelay on;
tcp_nopush off;

Best regards,

Mihai Vintila

It must have a positive impact, I am now able to access the server using
HTTP, but not using HTTPS.
nginx is running on my raspberry, port 80 for http, for 443 for https.
External ports are routed to according internal ports.

So HTTP is fine, HTTPS still returns an ERR_TUNNEL_CONNECTION_FAILED
from my
work computer. But from my phone, it works fine.
Error log is:
2015/04/23 15:04:04 [error] 2151#0: *8964 upstream prematurely closed
connection while reading response header from upstream, client:
109.99.99.99
, server: , request: “GET
/socket.io/?EIO=3&transport=polling&t=1429794125290-15&sid=ZjXxkYkMXrbfNkTbAACm
HTTP/1.1”, upstream:
http://127.0.0.1:8070/socket.io/?EIO=3&transport=polling&t=1429794125290-15&sid=ZjXxkYkMXrbfNkTbAACm”,
host: “truc:4321”, referrer: “https://truc:4321/jeedom/index.php?v=m&

Something that could help, maybe: I notice that referrer is a hostname,
some
for host, but I am accessing with an ip address. Is it expected ?

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,258187,258320#msg-258320

I have no clue why it is not working. So I took the computer from my
office
location and I did the test from another location, with a standard
internet
access: I have no issue at all.

It means that only the network between the computer and the nginx server
makes this error appears, it must have nothing to do with the computer.

I am still hoping to find some help here. I am pretty sure that the
<host:
“truc:4321”, referrer:
https://truc:4321/jeedom/index.php?v=d&p=history”>
is causing this issue, but I have no idea if this is a configuration of
the
nginx server and if I can do something around that.

Please help ! Thx.
GuiPoM

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,258187,258578#msg-258578

On Sat, May 02, 2015 at 10:52:31AM -0400, GuiPoM wrote:

Hi there,

I have no clue why it is not working. So I took the computer from my office
location and I did the test from another location, with a standard internet
access: I have no issue at all.

It means that only the network between the computer and the nginx server
makes this error appears, it must have nothing to do with the computer.

I also do not know why it fails.

Perhaps gathering more information will help find the cause.

When it fails:

  • what request is made?
  • what response is received? (application error, network timeout,
    something else)

When it works, and the same request is made:

  • what response is received?

If you can arrange that you can make the failing request on demand,
then you will probably have a better chance of identifying the problem.

ERR_TUNNEL_CONNECTION_FAILED can be associated with accessing https
through a proxy server. Do you use a proxy server on the “failing”
connection attempt? Does that proxy server have anything useful in
its logs?

I am still hoping to find some help here. I am pretty sure that the <host:
“truc:4321”, referrer: “https://truc:4321/jeedom/index.php?v=d&p=history”>
is causing this issue, but I have no idea if this is a configuration of the
nginx server and if I can do something around that.

If it matters: what is the configuration of the nginx server?

f

Francis D. [email protected]

Thank you for your answer. I can reproduce on demand ! BUTI am not
familiar
with nginx.
Could you give me some hints what to activate in order to provide
useful
information for debugging ?

I must connect through a proxy server but I will never be able to get
the
logs from there. I can get some logs about request arriving to nginx and
leaving it (but I already posted the only logs I am aware of).

Next follows the config. Hope it will help !

user www-data;
worker_processes 4;
pid /var/run/nginx.pid;

events {
  worker_connections 768;
  # multi_accept on;
}

http {

  ##
  # Basic Settings
  ##

  sendfile on;
  tcp_nopush off;
  tcp_nodelay on;
  keepalive_timeout 65;
  types_hash_max_size 2048;
  # server_tokens off;

  # server_names_hash_bucket_size 64;
  # server_name_in_redirect off;

  include /etc/nginx/mime.types;
  default_type application/octet-stream;

  ##
  # Logging Settings
  ##

  access_log /var/log/nginx/access.log;
  error_log /var/log/nginx/error.log;

  ##
  # Gzip Settings
  ##

  gzip on;
  gzip_disable "msie6";

  # gzip_vary on;
  # gzip_proxied any;
  # gzip_comp_level 6;
  # gzip_buffers 16 8k;
  # gzip_http_version 1.1;
  # gzip_types text/plain text/css application/json 
application/x-javascript
text/xml application/xml application/xml+rss text/javascript;

  ##
  # nginx-naxsi config
  ##
  # Uncomment it if you installed nginx-naxsi
  ##

  #include /etc/nginx/naxsi_core.rules;

  ##
  # nginx-passenger config
  ##
  # Uncomment it if you installed nginx-passenger
  ##

  #passenger_root /usr;
  #passenger_ruby /usr/bin/ruby;

  ##
  # Virtual Host Configs
  ##

  include /etc/nginx/conf.d/*.conf;
  include /etc/nginx/sites-enabled/*;
}


#mail {
#  # See sample authentication script at:
#  # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
#
#  # auth_http localhost/auth.php;
#  # pop3_capabilities "TOP" "USER";
#  # imap_capabilities "IMAP4rev1" "UIDPLUS";
#
#  server {
#    listen     localhost:110;
#    protocol   pop3;
#    proxy      on;
#  }
#
#  server {
#    listen     localhost:143;
#    protocol   imap;
#    proxy      on;
#  }
#}

Thanks.
GuiPoM

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,258187,258621#msg-258621

On Mon, May 04, 2015 at 02:19:45PM -0400, GuiPoM wrote:

Hi there,

Thank you for your answer. I can reproduce on demand ! BUTI am not familiar
with nginx.
Could you give me some hints what to activate in order to provide useful
information for debugging ?

You could follow http://nginx.org/en/docs/debugging_log.html to get all
sorts of information out of nginx – but I suspect that that will not
be immediately useful.

When things work, what is the sequence of requests made? access_log will
have that.

When things fail, what is the sequence of requests made? access_log will
also have that.

What is the first request in the sequence that fails, or otherwise does
not get the expected response, in the “fail” case?

Can you arrange a single “curl” command that works in one case and fails
in the other? That may help you analyse where things go wrong.

Next follows the config. Hope it will help !

Once the “failing” request is identified, the matching server{} and
location{} can be analysed to see what should happen.

(If it turns out that the “failure” happens before the request gets to
nginx – for example, during ssl negotiation – then the details of the
request are less important.)

But that config is presumably in one of the files mentioned in an
“include” directive.

include /etc/nginx/conf.d/.conf;
include /etc/nginx/sites-enabled/
;

Good luck with it,

f

Francis D. [email protected]

I will do so.

Two questions:
1/ In my config file /etc/nginx/nginx.conf, in section http, I already
have
the logging entries defined :
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;

I just tried to put debug as for example : “access_log
/var/log/nginx/access.log debug;”

But:
Restarting nginx: nginx: [emerg] unknown log format “debug” in
/etc/nginx/nginx.conf:36
nginx: configuration file /etc/nginx/nginx.conf test failed

I also tried to adapt to add the server section that I don’t have in my
own
config file, as your link mention
(http://nginx.org/en/docs/debugging_log.html#memory).

I did the same in one mentionned file : default_ssl
#access_log off;
#error_log /usr/share/nginx/www/jeedom/log/nginx.error;
access_log memory:32m debug;
error_log memory:32m debug;

Restarting nginx: nginx: [emerg] unknown log format “debug” in
/etc/nginx/sites-enabled/default_ssl:8
nginx: configuration file /etc/nginx/nginx.conf test failed

I a doing something wrong ?

2/ In error log, even if I can’t set a debug level, there is already
something strange I would like to change:

2015/05/02 13:25:05 [error] 2144#0: *4926 upstream prematurely closed
connection while reading response header from upstream, client:
XX.XX.XXX.XXX, server: , request: “GET
/socket.io/?EIO=3&transport=polling&t=1430565786187-49&sid=IIJ1gX_E4Ny_ojN8AACB
HTTP/1.1”, upstream:
http://127.0.0.1:8070/socket.io/?EIO=3&transport=polling&t=1430565786187-49&sid=IIJ1gX_E4Ny_ojN8AACB”,
host: “hostname.dtdns.net:9876”, referrer:
https://hostname.dtdns.net:9876/jeedom/index.php?v=m&

How host and referrer can be filled with a dynamic dns name ? How nginx
is
aware of this information ? I am requesting with an IP address, so no
chance
this information come from the sender.

Could this configuration be erroneous ?
(/etc/nginx/sites-enabled/default_ssl)

location /socket.io/ {
proxy_pass http://127.0.0.1:8070/socket.io/;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection “Upgrade”;
proxy_set_header Host $host;
proxy_redirect off;
proxy_read_timeout 6000;
}

Thx.
GuiPoM

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,258187,258670#msg-258670

On Tue, May 05, 2015 at 04:00:11PM -0400, GuiPoM wrote:

Hi there,

I just tried to put debug as for example : “access_log
/var/log/nginx/access.log debug;”

But:
Restarting nginx: nginx: [emerg] unknown log format “debug” in
/etc/nginx/nginx.conf:36
nginx: configuration file /etc/nginx/nginx.conf test failed

Does “nginx -V” show “–with-debug”?

“debug” is for error_log, not for access_log.

https://hostname.dtdns.net:9876/jeedom/index.php?v=m&

How host and referrer can be filled with a dynamic dns name ? How nginx is
aware of this information ? I am requesting with an IP address, so no chance
this information come from the sender.

When you copy-paste the commands issued and the responses gathered,
it may become clearer where all of the information is coming from.

My guess is that you are issuing one request with an ip address, and
that is returning a http redirect to a hostname; and then you are
issuing
the next request to that hostname.

But until you show your work, all anyone can do here is guess.

            proxy_read_timeout 6000;
    }

This looks like the connection is using WebSockets.

Does your proxy server at work allow WebSocket connections to pass
through it?

Can you successfully connect to any WebSocket service anywhere from
work? If not, the problem may not be on the nginx side.

Good luck with it,

f

Francis D. [email protected]

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs