v2rayA TPROXY on OpenWrt 25.12.5 triggers OOM and leaves Xray holding port 20170

Describe the bug

Describe the bug

On a clean official OpenWrt 25.12.5 installation, enabling TPROXY in v2rayA causes very high memory usage in the v2raya process. The kernel eventually invokes the OOM killer and terminates v2raya.

Because the OpenWrt procd service is configured with respawn, v2rayA is started again while the previous Xray child process may still be alive and listening on port 20170. The restarted v2rayA instance then fails with:

failed to start v2ray-core: port is occupied by xray(<pid>): 20170```

The same setup works when the transparent proxy implementation is changed from **TPROXY** to **Redirect**.

This was reproduced on OpenWrt 25.12.5. It may affect other 25.12.x builds, but that has not yet been verified on additional devices.

The system was a fresh installation with no other transparent-proxy software installed:

* no PassWall / PassWall2
* no HomeProxy
* no standalone Xray service
* no sing-box service
* only v2rayA and its Xray dependency

I am not certain whether the root cause belongs to `openwrt/openwrt`, the v2rayA package in `openwrt/packages`, or v2rayA upstream. Please redirect this report if another repository is more appropriate.

### OpenWrt version

r33051-f5dae5ece4

### OpenWrt release

25.12.5

### OpenWrt target/subtarget

qualcommax/ipq50xx

### Device

Linksys MX2000

### Image kind

Official downloaded image

### Steps to reproduce

1. Flash the official OpenWrt 25.12.5 image on a Linksys MX2000.
2. Install only v2rayA, Xray and the required TPROXY dependencies.
3. Configure a working proxy server in v2rayA.
4. Open v2rayA settings.
5. Enable transparent proxy.
6. Select `tproxy` as the transparent proxy implementation.
7. Use `RoutingA` as the traffic-splitting mode.
8. Save and apply the configuration.
9. Observe memory usage and kernel logs.
With `redirect`, the service starts normally. With `tproxy`, memory usage rises and the kernel kills v2rayA.

### Actual behaviour

The router has approximately 432 MiB of usable RAM and no swap:

```text
MemTotal:       442860 kB
MemAvailable:   187840 kB
SwapTotal:           0 kB

During the failure, v2rayA reached roughly 219 MiB anonymous RSS. The OOM event was reproduced more than once at almost the same memory usage:

Out of memory: Killed process 4530 (v2raya)
total-vm:1562460kB, anon-rss:219264kB, file-rss:4kB

Second occurrence:

Out of memory: Killed process 4724 (v2raya)
total-vm:1496932kB, anon-rss:219136kB, file-rss:0kB

At the same time, Xray used much less resident memory:

[4699] xray rss: 2738 pages
[4894] xray rss: 1109 pages

The service init script contains:

procd_set_param respawn

After the OOM kill, the old Xray process can remain alive. The respawned v2rayA process then reports:

failed to start v2ray-core: port is occupied by xray(<pid>): 20170

Expected behaviour

• Enabling TPROXY should not cause v2rayA to consume enough memory to trigger the OOM killer on a device with approximately 512 MiB RAM.
• Restarting or respawning v2rayA should not leave an orphaned Xray process.
• Only one Xray process should exist.
• Port 20170 should be released before a replacement core is started.
• TCP and UDP transparent proxying should work through TPROXY without an OOM event.

Additional info

Relevant service configuration:

v2raya.config.enabled='1'
v2raya.config.address='0.0.0.0:2017'
v2raya.config.ipv6_support='auto'
v2raya.config.nftables_support='auto'
v2raya.config.log_level='info'
v2raya.config.log_max_days='3'
v2raya.config.log_disable_color='1'

The init script also configures:

procd_set_param limits core="unlimited"
procd_set_param limits nofile="1000000 1000000"
procd_set_param respawn

The immediate port 20170 occupied error appears to be secondary to the OOM event: v2rayA is killed, procd respawns it, and the old Xray child remains alive.

Useful areas to investigate may include:

• memory allocations while generating or applying TPROXY rules
• repeated loading or duplication of routing datasets
• process lifecycle and child cleanup when v2rayA is killed
• whether Xray should receive a parent-death signal on Linux
• whether procd respawn can race with an existing Xray child

I can provide additional logs or test a diagnostic build if required.

Diffconfig

Terms

• I am reporting an issue for OpenWrt, not an unsupported fork.

Start by reproducing the TPROXY configuration on OpenWrt 25.12.5 and inspect memory use and kernel OOM logs. Read the v2rayA package service init script, especially procd_set_param respawn, and trace TPROXY rule or routing-data application plus Xray child cleanup. Done means identifying the memory-growth cause and ensuring a respawn leaves no old Xray process holding port 20170.