Does Xray produce asymmetric TX/RX traffic? #6659
Replies: 3 comments 1 reply
|
Your reasoning is correct — for an exit node the bulk traffic really should be close to symmetric, since every byte fetched from the internet is a byte forwarded to a client. ACKs and protocol overhead are a few percent, nowhere near what you are seeing. But the interesting part is in your own table, and it is not a ratio problem at all. Subtract TX from RX for each day: The difference is about 3.2 GiB every single day, and it barely moves. Look at 07-23 in particular: your proxy traffic that day was roughly fifteen times any other day, and the excess RX stayed at 3.27 GiB. If this were a ratio effect — overhead, ACKs, anything proportional to the work Xray does — the gap would have grown with the traffic. It did not. So the ratio is a red herring. What you actually have is a constant inbound stream of roughly 3.2 GiB per day, about 310 kbit/s sustained, that has nothing to do with your proxy usage, sitting on top of proxy traffic that is symmetric exactly as you expected. On a busy day it disappears into the noise and the numbers look sane; on a quiet day it is most of your RX and the ratio looks alarming. That is worth chasing on its own terms, and the shape of it is mildly reassuring about the compromise worry. A compromised host is normally loud in the other direction — exfiltration, spam, or acting as a DDoS source all show up as excess TX. Inbound-only that ignores whether your service is busy looks far more like something pointed at you than something running on you, which is unsurprising for a public IP running this kind of service. Since you know the volume and rate now, it is a bounded thing to find. Per-source byte counters will name it quickly — Whichever it turns out to be, the answer to the question you asked is no: Xray is not producing the asymmetry. Your proxy traffic is balanced once the constant is taken out, and the same arithmetic is probably worth running on #3692's numbers too. |
|
Your model is right, and your own numbers back it up. Look at the idle days: RX sits at 3.4-4.0 GiB while TX is 0.5-0.8 GiB. Now take the busy day, 07-23, at 11.17 RX / 7.90 TX and subtract that idle floor from both: +7.5 GiB RX and +7.2 GiB TX. The part that is actually being proxied is symmetric to within a few percent, exactly as you expected. What sits underneath it is a constant ~3.5 GiB/day of RX that does not move with usage, roughly 340 kbit/s arriving around the clock whether anyone is connected or not. So the question isn't why a proxy is asymmetric, it's what that steady inbound stream is. Two measurements separate the cases. Count what arrives on the proxy ports versus everything else. A rule with no target only counts and falls through, so this changes nothing: If the bytes pile up in rules 2 and 3, it is unsolicited traffic to your public IP and has nothing to do with Xray. If they pile up in rule 1, it is arriving on the listener and you can look at Xray's own accounting. For that you need stats enabled: "stats": {},
"api": { "tag": "api", "services": ["StatsService"] },
"policy": { "system": {
"statsInboundUplink": true, "statsInboundDownlink": true,
"statsOutboundUplink": true, "statsOutboundDownlink": true } }with an API inbound bound to 127.0.0.1, then sample twice a couple of minutes apart: Don't use The four numbers give you a closed model. Whatever the interface counts beyond that is not passing through Xray at all. For reference, I sampled my own exit node over 120 seconds while it was carrying normal traffic and got 12.4 MiB rx against 12.3 MiB tx. That is what a relay looks like. One thing worth ruling out first, since it costs a minute: confirm the counters mean what you think. Download a large file on the box and watch which direction moves. Downloading 200 MB on the server itself should move the first number by ~200 MB. If the second one moved instead, the labels are swapped on your virtualization and everything above reads differently. My guess for where you'll land: rule 2 plus rule 3, i.e. background noise against a public IP. Scanners and active probes are normal, but 340 kbit/s sustained is on the high side, so |
|
Thank you very much! I have stopped xray service for a night and then checked stats, looks like this: then i checked counters: and now thinking that this is indeed a public scanning only. Thank you again for such a comprehensive support! I close the ticked for now it is evident that the asymmetry is present without xray. |
|
One thing in the counters you posted is worth a look before filing this under scanning: they do not add up to what vnstat sees. Everything that ended its path in the INPUT chain comes to about 58 GiB: 45.4 GiB RELATED,ESTABLISHED and 12.9 GiB dropped by the policy, with the rest under 40 MB. So the unsolicited part that iptables saw is 28% of the proxy's own inbound. Your July table says the opposite: the quiet days carry 2.8 to 3.4 GiB of RX on top of 0.5 to 0.7 GiB of proxy traffic, four to seven times as much. And if those counters go back to the boot 45 days ago, the DROP line works out at 12 MiB an hour, against the 28 to 165 MiB an hour you measured with Xray stopped. Counters reset when the rules are reloaded, so that last figure carries a caveat the ratio does not, but either way most of the floor never reached the IPv4 INPUT chain. What the interface counts and iptables never sees is everything that is not IPv4: ARP, and IPv6 including neighbour discovery and router advertisements, which only |
Uh oh!
There was an error while loading. Please reload this page.
I have dedicated VPS server to serve exclusively as Xray exit node and the following typical vnstat output:
Conceptually every single chunk of data that my VPS downloads from the internet (RX) must be sent back to xray VLN client (TX), with additional RX overhead for:
But could that difference be that high? I am not into networking really but various AI chats suggested inspecting running logs to rule out VPS being compromised and all seems OK.
I know a similar discussion yet unanswered #3692 perhaps we both misinterpret
vnstat?All reactions