eb 22, 2024 at 1:46 AM J Carter wrote:
> Hello,
>
> On Tue, 20 Feb 2024 11:57:27 +0800
> Kin Seng wrote:
>
> > Hi J Carter,
> >
> > Thank you for your reply.
> > I am capturing the packet from firewall, and the filtering is as per
> below
> > for the p
session, it seems like close_wait is
the symbol that the closing is from external ( in this case client app is
connect to nginx proxy), is this right?
On Tue, Feb 20, 2024, 10:06 AM J Carter wrote:
> Hello,
>
> On Tue, 20 Feb 2024 09:40:13 +0800
> Kin Seng wrote:
>
t; On Mon, 19 Feb 2024 16:24:48 +0800
> Kin Seng wrote:
>
> [...]
> > Please refer to the attachments for reference.
> >
> > On Mon, Feb 19, 2024 at 4:24 PM Kin Seng wrote:
> > > After capturing the tcp packet and check via wireshark, I found out
> that
>
Hi Roman,
Thanks for the suggestion. Let me get the debugging log up and retest again.
On Tue, Feb 20, 2024, 1:02 AM Roman Arutyunyan wrote:
> Hi,
>
> On Mon, Feb 19, 2024 at 04:24:04PM +0800, Kin Seng wrote:
> > My current nginx setup always kill the TCP connection aft
Please refer to the attachments for reference.
On Mon, Feb 19, 2024 at 4:24 PM Kin Seng wrote:
> My current nginx setup always kill the TCP connection after 5 minutes of
> inactivity, i.e no transaction.
> [From wireshark, nginx send RST to upstream server and then send FIN,ACK
> t
My current nginx setup always kill the TCP connection after 5 minutes of
inactivity, i.e no transaction.
[From wireshark, nginx send RST to upstream server and then send FIN,ACK to
downstream client]
I have this setup which requires TLS1.2 connection connecting from my
internal network [client app
