iOS high memory usage/memory leak

[nbghere]

Integrity requirements

• I have read all the comments in the issue template and ensured that this issue meet the requirements.
• I confirm that I have read the documentation, understand the meaning of all the configuration items I wrote, and did not pile up seemingly useful options or default values.
• I provided the complete config and logs, rather than just providing the truncated parts based on my own judgment.
• I searched issues and did not find any similar issues.
• The problem can be successfully reproduced in the latest Release

Description

Memory leaks are persistent when using certain iOS apps. The pprof profiles are attached.

Metrics.zip

Reproduction Method

none

Client config

{
  "dns" : {
    "queryStrategy" : "UseIPv4"
  },
  "inbounds" : [
    {
      "listen" : "127.0.0.1",
      "port" : 10808,
      "protocol" : "socks",
      "settings" : {
        "auth" : "noauth",
        "udp" : true
      },
      "sniffing" : {
        "destOverride" : [
          "quic",
          "http",
          "tls"
        ],
        "enabled" : true,
        "excludedDomains" : [

        ],
        "metadataOnly" : false,
        "routeOnly" : true
      },
      "tag" : "socks-in"
    },
    {
      "listen" : "127.0.0.1",
      "port" : 10809,
      "protocol" : "http",
      "settings" : {
        "auth" : "noauth",
        "udp" : true
      },
      "sniffing" : {
        "destOverride" : [
          "quic",
          "http",
          "tls"
        ],
        "enabled" : true,
        "excludedDomains" : [

        ],
        "metadataOnly" : false,
        "routeOnly" : true
      },
      "tag" : "http"
    },
    {
      "listen" : "127.0.0.1",
      "port" : 10820,
      "protocol" : "socks",
      "settings" : {
        "auth" : "noauth",
        "udp" : true
      },
      "sniffing" : {
        "destOverride" : [
          "quic",
          "http",
          "tls"
        ],
        "enabled" : true,
        "excludedDomains" : [

        ],
        "metadataOnly" : false,
        "routeOnly" : true
      },
      "tag" : "socks-direct"
    }
  ],
  "outbounds" : [
    {
      "protocol" : "vless",
      "settings" : {
        "testpre" : null,
        "testseed" : null,
        "vnext" : [
          {
            "address" : "example.com",
            "port" : 443,
            "users" : [
              {
                "encryption" : "none",
                "flow" : "xtls-rprx-vision",
                "id" : "uuidhere",
                "level" : 8,
                "security" : "auto"
              }
            ]
          }
        ]
      },
      "streamSettings" : {
        "network" : "tcp",
        "realitySettings" : {
          "fingerprint" : "chrome",
          "publicKey" : "pbkhere",
          "serverName" : "example.com",
          "shortId" : "111111123123123",
          "show" : false,
          "spiderX" : ""
        },
        "security" : "reality",
        "tcpSettings" : {
          "header" : {
            "type" : "none"
          }
        }
      },
      "tag" : "proxy"
    },
    {
      "protocol" : "freedom",
      "tag" : "direct"
    },
    {
      "protocol" : "blackhole",
      "tag" : "block"
    }
  ],
  "policy" : {
    "levels" : {
      "8" : {
        "bufferSize" : 3,
        "connIdle" : 300,
        "downlinkOnly" : 4,
        "handshake" : 3,
        "uplinkOnly" : 2
      }
    },
    "system" : {

    }
  },
  "remarks" : "Test",
  "routing" : {
    "domainStrategy" : "AsIs",
    "rules" : [
      {
        "inboundTag" : [
          "socks-direct"
        ],
        "outboundTag" : "direct"
      }
    ]
  }
}

Server config

none

Client log

none

Server log

none

[Fangliding]

IOS的50 mb限制太小了 pprof里的堆内存也就十几MB而已

[iambabyninja]

This issue reminded me of a previously mentioned problem:

#4422 (comment)
#4422 (comment)

For some reason, when I use DoU, peak memory usage effectively reaches the tunnel’s memory limit. With the exact same configuration but using DoH, memory usage stays within normal bounds without any spikes.

@Fangliding could it be that we captured the pprof incorrectly?

[Fangliding]

udp 确实需要开启额外的goroutine以管理其状态 略微消耗比doh更多的资源 但是不应该是问题 这个功能广泛使用但是我们此前从未收到过udp dns的性能问题 说实话很难在50mb的limit下断定某个组件存在 leak 问题 它可能就是消耗多了点

[nbghere]

udp 确实需要开启额外的goroutine以管理其状态 略微消耗比doh更多的资源 但是不应该是问题 这个功能广泛使用但是我们此前从未收到过udp dns的性能问题 说实话很难在50mb的limit下断定某个组件存在 leak 问题 它可能就是消耗多了点

I wrote a script that pulled data from the /debug/pprof/heap and /debug/pprof/goroutine metrics every second.
I reproduced the memory leak. This archive contains the entire data set, second by second, before the kernel crash. I hope this information helps understand the problem.

pprof_20260415_170428.zip

[nbghere]

@Fangliding I ask you, please do not abandon poor iOS users. I really hope this information will help identify the cause of the leak specifically due to UDP

[Meo597]

@nbghere 麻烦测试一下 #5934
我关心现在 iOS 下内存表现如何

[RPRX]

@Fangliding I ask you, please do not abandon poor iOS users. I really hope this information will help identify the cause of the leak specifically due to UDP

啥叫 poor iOS users？？288 刀的 iOS 家人们必须是第一位的

[nbghere]

@nbghere 麻烦测试一下 #5934 我关心现在 iOS 下内存表现如何

Yes, of course. I’ll build it and test it if possible, and I’ll share the results

[Fangliding]

这整个反馈就是无效的 他发的这个新pprof从始至终堆内存10MB不到 开了102个goroutine 比最上面发的占用还低 看起来像刚启动 这还reopen跟会哭的孩子有奶吃没区别
至于那个 udp dns 完全就是未证实的跟这个issue没关系 这里甚至都没写dns服务器

[nbghere]

这整个反馈就是无效的 他发的这个新pprof从始至终堆内存10MB不到 开了102个goroutine 比最上面发的占用还低 看起来像刚启动 这还reopen跟会哭的孩子有奶吃没区别 至于那个 udp dns 完全就是未证实的跟这个issue没关系 这里甚至都没写dns服务器

Yes, the tunnel had just started and I used one app for testing that 100% causes a memory leak due to UDP.
I can avoid using this app, but in any case, any iOS app eventually triggers this issue, which causes the tunnel to disconnect due to memory limits.

[RPRX]

等新版 HAPP 出来后他测测看看吧，这个 issue 转为关注 #5944 (comment) 问题也行

开着 issue 能受到更多关注，毕竟 Xray-core 版 XHTTP 在 iOS 上也挺吃内存的，看谁能找到关键点优化下

[nbghere]

这整个反馈就是无效的 他发的这个新pprof从始至终堆内存10MB不到 开了102个goroutine 比最上面发的占用还低 看起来像刚启动 这还reopen跟会哭的孩子有奶吃没区别 至于那个 udp dns 完全就是未证实的跟这个issue没关系 这里甚至都没写dns服务器

I collected metrics via the core API. Could you advise how to properly capture them on a mobile device so they are actually useful? What information should I provide? I’m concerned that my current method might not be capturing the issue.

[Fangliding]

I collected metrics via the core API. Could you advise how to properly capture them on a mobile device so they are actually useful? What information should I provide? I’m concerned that my current method might not be capturing the issue.

答案就是没 泄露意味着存在动态创建的资源没有释放 在golang中绝大多数情况下是goroutine 这会导致内存占用存在极其明显的随时间递增而无法回落 比如开启一个小时占用100MB 开启两个小时占用200MB 只用对比两个事件点很容易就可以发现产生膨胀的区域 但是xray本身启动就占用二三十MB 到被kill几乎没有对比空间 除非能在其他平台复现（但是从未受到过报告）