You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Noticed that possible memory leak occurred in xray-core with routing policies #104
Both in Happ with xray-core 25.9 and V2BOX with xray-core 25.7 in iOS 18.7, I noticed that the memory used was gradually increasing from around 12M initially to finally 50M and made the app crash.
It took about from less than one hour to several hours for the final crash to occur.
If any further info about this topic is needed, I will provide as far as I can.
unfortunately a known behavior on mobile platforms (especially iOS of course)
you can try:
reducing / cutting geo files to save a couple of mb
tweaking memory limits and configuration parameters
however, these measures are mostly band-aids and won’t solve the root cause...
xray-core is not optimized for mobile environments
(for example, when using transports like xhttp, it’s easy to observe goroutine spikes (from ~100 up to several thousand) with light usage - like a few YouTube shorts can trigger this)
this is a limitation of xray-core itself
this is something users have to accept and deal with
Both in Happ with xray-core 25.9 and V2BOX with xray-core 25.7 in iOS 18.7, I noticed that the memory used was gradually increasing from around 12M initially to finally 50M and made the app crash.
It took about from less than one hour to several hours for the final crash to occur.
If any further info about this topic is needed, I will provide as far as I can.
Maybe if we can chunk the geo files that can help. But for now HACK: just restart the tunnel when fails.
I’m seeing the same issue on iOS. In my testing, the memory growth comes from the xray-core/Go stack rather than the app wrapper. I eventually rewrote the core in Rust, which resolved the memory problem in my use case.
I’m seeing the same issue on iOS. In my testing, the memory growth comes from the xray-core/Go stack rather than the app wrapper. I eventually rewrote the core in Rust, which resolved the memory problem in my use case.
Yep, but I made not like saynig codex "make me better lib than xray-core". I passed a lot of agent loops using oracle tests with xray-core. Also, I use benchmarks.
This library is already integrated into one application (for now only the beta Apple TV version) and also, an application built on this library is currently being reviewed, which works like Streisand or Foxray
Yep, but I made not like saynig codex "make me better lib than xray-core". I passed a lot of agent loops using oracle tests with xray-core. Also, I use benchmarks. This library is already integrated into one application (for now only the beta Apple TV version) and also, an application built on this library is currently being reviewed, which works like Streisand or Foxray
we got vibed critical network programs before gta 6
Yep, but I made not like saynig codex "make me better lib than xray-core". I passed a lot of agent loops using oracle tests with xray-core. Also, I use benchmarks. This library is already integrated into one application (for now only the beta Apple TV version) and also, an application built on this library is currently being reviewed, which works like Streisand or Foxray
we got vibed critical network programs before gta 6
but this really solves the memory problem on iOS
Besides, I think Rust is better suited for this kind of tasks.
Yep, but I made not like saynig codex "make me better lib than xray-core". I passed a lot of agent loops using oracle tests with xray-core. Also, I use benchmarks. This library is already integrated into one application (for now only the beta Apple TV version) and also, an application built on this library is currently being reviewed, which works like Streisand or Foxray
we got vibed critical network programs before gta 6
but this really solves the memory problem on iOS Besides, I think Rust is better suited for this kind of tasks.
Good for you man. I don't have money to buy tokens for top tier models :(
I checked your repo, its 200k + LOC, maybe costed 200/300 $ on tokens :) Huge for just solving mem problem
Edit : @aimalygin do you have tg? I have a really good idea to solve it without so much work, can you send me a hi on tg (same username) or like via mail(check my profile readme)?
Yep, but I made not like saynig codex "make me better lib than xray-core". I passed a lot of agent loops using oracle tests with xray-core. Also, I use benchmarks. This library is already integrated into one application (for now only the beta Apple TV version) and also, an application built on this library is currently being reviewed, which works like Streisand or Foxray
we got vibed critical network programs before gta 6
but this really solves the memory problem on iOS Besides, I think Rust is better suited for this kind of tasks.
Good for you man. I don't have money to buy tokens for top tier models :(
I checked your repo, its 200k + LOC, maybe costed 200/300 $ on tokens :) Huge for just solving mem problem
Edit : @aimalygin do you have tg? I have a really good idea to solve it without so much work, can you send me a hi on tg (same username) or like via mail(check my profile readme)?
Activity
InfiniteFalltrough commentedon Dec 22, 2025
unfortunately a known behavior on mobile platforms (especially iOS of course)
you can try:
however, these measures are mostly band-aids and won’t solve the root cause...
xray-core is not optimized for mobile environments
(for example, when using transports like xhttp, it’s easy to observe goroutine spikes (from ~100 up to several thousand) with light usage - like a few YouTube shorts can trigger this)
this is a limitation of xray-core itself
this is something users have to accept and deal with
alexwwang commentedon Jan 23, 2026
Thank you for your patient explanation. It’s very clear and reasonable. I understand it completely. Wish you a good day.
codewithtamim commentedon Apr 1, 2026
Maybe if we can chunk the geo files that can help. But for now HACK: just restart the tunnel when fails.
mklnz commentedon Jun 5, 2026
I'm using geoip-only-cn-private.dat instead of the full geoip and geosite files, seems to work
edit: nevermind, it's still slowly increasing but generally it's not an issue. Would periodic manual GC help?
aimalygin commentedon Aug 27, 2026
I’m seeing the same issue on iOS. In my testing, the memory growth comes from the xray-core/Go stack rather than the app wrapper. I eventually rewrote the core in Rust, which resolved the memory problem in my use case.
codewithtamim commentedon Aug 27, 2026
vibe?
aimalygin commentedon Aug 27, 2026
Yep, but I made not like saynig codex "make me better lib than xray-core". I passed a lot of agent loops using oracle tests with xray-core. Also, I use benchmarks.
This library is already integrated into one application (for now only the beta Apple TV version) and also, an application built on this library is currently being reviewed, which works like Streisand or Foxray
codewithtamim commentedon Aug 28, 2026
we got vibed critical network programs before gta 6
aimalygin commentedon Aug 28, 2026
but this really solves the memory problem on iOS
Besides, I think Rust is better suited for this kind of tasks.
codewithtamim commentedon Aug 28, 2026
Good for you man. I don't have money to buy tokens for top tier models :(
I checked your repo, its 200k + LOC, maybe costed 200/300 $ on tokens :) Huge for just solving mem problem
Edit :
@aimalygin do you have tg? I have a really good idea to solve it without so much work, can you send me a hi on tg (same username) or like via mail(check my profile readme)?
aimalygin commentedon Aug 28, 2026
yep, the same nick as here