Bug #6421
closed
Nginx keepalive_timeout 65 breaking some captive portal redirects
0%
Description
Using nginx as the captive portal web server with keepalive_timeout 65 causes attempts to access sites after authentication to use same TCP/HTTP session to captive portal instead of a new session to the destination site. This gives the appearance of not being redirected to the destination site after login with the portal page just "hanging" after login is pressed. This only manifests itself if the same destination site is attempted by the client both pre- and post-auth.
Setting keepalive_timeout 0 in the portal nginx config forces clients start a new TCP/HTTP session for each web element and corrects this. A short but > 0 value like 1 or 2 should keep most of the keepalive benefits during portal page load yet cause new TCP sessions to be used after all but very quick portal logins.
It looks like lighttpd had:
server.max-keep-alive-requests = 15
server.max-keep-alive-idle = 30
I am not certain but this could explain some of the strange login hangs/timeouts I used to see.
Updated by Chris Buechler almost 8 years ago
- Subject changed from Nginx keepalive_timeout 65 breaking some captive portal logins. to Nginx keepalive_timeout 65 breaking some captive portal redirects
- Status changed from New to Feedback
- Assignee set to Chris Buechler
- Affected Version changed from 2.3.1 to All
Good catch, Chris. Fix pushed to disable the keepalive in captive portal's nginx instances. In that circumstance, the redirect was always problematic, nginx just made the timeout longer. Confirmed situation that would hang on the post-auth redirect every time for just upwards of a minute now immediately redirects post-login.