Are you certain the docker host is listening on port 80? It might be redirected from port 80 to whatever port it is listening on using the built-in firewall.
If you are running IPTABLES, you could check this by using:
iptables -L -t nat
You would then see a chain named DOCKER which will tell you what redirects are in place, similar to this:
Chain DOCKER (2 ...
from my understanding you are only able to have one default route which it seems debian will take the first interface configured with a gateway as the default route. in your case eth0, if you are attempting to route to a different subnet within your local network. Your system is on 192.168.1.0/24 network but you would require a static route only to route 192....
Since you mentioned incoming connections and in particular replies going the wrong way, it sounds like it might be enough to have packets sent with the source address 10.150.114.190 (eth2) use the routes that go via 10.150.114.191, and similarly for eth1. Policy-based (source) routing should be able to do that.
It should basically boil down to something like:...
This will be dependant on the VPN you are using. as @roaima said, if it is openvpn, you can add it to the client config as route [ip] 255.255.255.0 [gateway].
Where "ip" is actually the subnet you want to route, and gateway is the gateway of your vpn network interface.
For things like wireguard, here is a reddit discussion on the subject:
I'm sorry to say this, but what you either need is better understanding of TCP/IP, or you don't need TCP/IP at all.
Application logging is probably the answer to your problem, but it depends on your applications.
You write "nginx sends another packet from the port 4444 to the port 7777". I'm quite sure that it does not send from a fixed port. Doing ...
Your OS likely does some short term buffering before sending. E.g. the Linux man page tcp(7) mentions the TCP_NODELAY option to disable that (see also setsockopt(2)):
If set, disable the Nagle algorithm. This means that
segments are always sent as soon as possible, even if
there is only a small amount of data. When not set, data
is buffered ...
Something which you could do is to set a fallback IP in your dhclient.conf so APIPA (automatic private IP addressing) doesn't come into play when your DHCP isn't available. however, this has to be set statically and is not linked to your last DHCP-Lease.
Example: Post concerning this topic