Search results

Yes, no worry. If csf block UDP outgoing, it could block the DNS query.

It is PHP internal crash when handle the SIGTERM signal. Maybe try different PHP version see if crash stops. If crash continue, you may submit a bug report to php.net .

http://httpd.apache.org/docs/current/mod/mod_include.html#ssilastmodified it will be supported in LSWS 5.3 currently, the only option how with 5.2.7 http://httpd.apache.org/docs/current/mod/mod_include.html#xbithack

It will be available soon with LSWS 5.3 release, 5.3RC1 will come soon.

The random UDP port is likely opened by the Asynchronize DNS resolver library used in the server. It should not cause any security issue. see if we can turn it off. it has nothing to do with QUIC.

That's due to the debug build of 5.2.7, please update to 5.2.7 build 4 to switch the license, /usr/local/lsws/admin/misc/lsup.sh -f -v 5.2.7 then you can update to the debug build if still need. /usr/local/lsws/admin/misc/lsup.sh -d -f -v 5.2.7

it could be a IPv6 routing/firewall problem. try to telnet to the IPv6:Port directly from different server/localhost see if you can connect to it.

Please try the latest debug build of 5.2.7 see if it fixes the rewrite rule problem. /usr/local/local/lsws/admin/misc/lsup.sh -d -f -v 5.2.7

If keepalive timeout is longer than x seconds, then the connection belong to one client is more likely reused by that client. the connection cannot be shared among clients.

Hi Ryan, Welcome! 5.2.7 build 2 has been pushed a few minutes ago. It is a bug in our QUIC code. The bug was that a RST_STREAM frame was ignored if the peer already sent a FIN. This could cause a stall, as the server would continue to send STREAM frames after the reset, until it eventually...

Thank you for the confirmation, we will release the fix in 5.2.7 build 2.

Have you got a chance to give it a try? :-)

Yes, we have a debug build pushed, you can update to it with command /usr/local/lsws/admin/misc/lsup.sh -d -f -v 5.2.7 you can try enabling QUIC.

Thanks for the debug log, it is helpful. I think might be related to QUIC transport. may hit a bug. Our developer is look at it. In the mean time, can you try turning off QUIC, just use HTTP/2 to serve the video file, see if it fixes the stalling problem.

We could not easily reproduce this problem internally with chrome on mac. Can you turn on web server debug logging, then try to reproduce the problem. send us the log file for analysis. You need to * remove old /usr/local/apache/logs/error_log * login to server webadmin, then under...

It could be temporary problem with our own web site. please try again.

How about turning on debug logging temporarily?

Please check the error log, it should give the reason of 403.

/usr/bin/lsphp is not in cagefs I guess.

Please check stderr.log, see if the reason why PHP crashes has been logged there.