XrayR-project / XrayR

A Xray backend framework that can easily support many panels. 一个基于Xray的后端框架,支持V2ay,Trojan,Shadowsocks协议,极易扩展,支持多面板对接
https://xrayr-project.github.io/XrayR-doc/
Mozilla Public License 2.0
2.03k stars 817 forks source link

invalid memory address or nil pointer dereference !!! #204

Closed MrVb0 closed 1 year ago

MrVb0 commented 1 year ago

Hello I use XRAYR and V2BOARD But the connection is disconnected every few seconds, and when I saw the log, I noticed this error : xrayr-bug

Please help me to solve the problem

Septrum101 commented 1 year ago

Cannot recall, could you provide the condition and config.yml?

MrVb0 commented 1 year ago

In config.yml everything is normal I have this problem on almost every 10 servers I have, along with many disconnections It disconnects every few minutes and connects after a few seconds It is a boring situation Could this problem be related to v2board?

pocketW commented 1 year ago

Are you using the global device limit with redis right now?

MrVb0 commented 1 year ago

Hello, yes, I have created a separate server for Redis and connected all servers to one Redis server

MrVb0 commented 1 year ago

Screenshot 2023-01-10 144742 This setting information is related to global device limit I have connected all xrayr servers and all nodes of each server to a separate redis server.

pocketW commented 1 year ago

Similar issues #111 #131 have been reported. We thought this issue has been fixed after the refactoring of the global device limit. Since you are using the latest version (v0.8.8), we might need to further investigate this problem. Thanks for your reporting again.

MrVb0 commented 1 year ago

Thank you for your reply. So I will wait for the new update. Thank you for making and updating this great script

mokhtarabadi commented 1 year ago

I have the same problem, but GlobalDeviceLimitConfig is disabled. I used PMPanel, ProxyProtocol, Nginx stream, and Trojan I edited pmpanel.go to add support for ws and h2

mokhtarabadi commented 1 year ago

@pocketW if you need tell me I will share my server details so you can check it, I have about 500 active users and now they have bad experience with panel, I think this is emergency bug

pocketW commented 1 year ago

@pocketW if you need tell me I will share my server details so you can check it, I have about 500 active users and now they have bad experience with panel, I think this is emergency bug

Hi, sorry for the inconvenience. Please kindly provide the configuration file and log if possible. Besides, could you also try to use the old version to see if the problem still exists? You can install the old version by using XrayR install v0.x.x.

Septrum101 commented 1 year ago

@pocketW if you need tell me I will share my server details so you can check it, I have about 500 active users and now they have bad experience with panel, I think this is emergency bug

Hi, sorry for the inconvenience. Please kindly provide the configuration file and log if possible. Besides, could you also try to use the old version to see if the problem still exists? You can install the old version by using XrayR install v0.x.x.

I think it could happen in this case, due to some reason the UDP conn has closed, But the dispatcher still xfer the traffic to the UDP conn.

mokhtarabadi commented 1 year ago

@pocketW if you need tell me I will share my server details so you can check it, I have about 500 active users and now they have bad experience with panel, I think this is emergency bug

Hi, sorry for the inconvenience. Please kindly provide the configuration file and log if possible. Besides, could you also try to use the old version to see if the problem still exists? You can install the old version by using XrayR install v0.x.x.

I first used the master branch, and I encounter the bug (also enabling/disabling global device limit not affected)

systemd logs:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x93de20]
goroutine 21532 [running]:
github.com/xtls/xray-core/transport/internet/udp.(*Dispatcher).Dispatch(0xc00138b980?, {0x3690098, 0xc001219500}, {{0x36921d8?, 0xc000a33670?}, 0xb8c0?, 0xc0?}, 0xc0012194d0)
        github.com/xtls/xray-core@v1.7.2/transport/internet/udp/dispatcher.go:86 +0x1e0
github.com/xtls/xray-core/proxy/trojan.(*Server).handleUDPPayload(0xc001530d50, {0x3690098, 0xc0012d5e90}, 0x0?, 0xc001219440, {0x3694540?, 0xc0014e9ad0})
        github.com/xtls/xray-core@v1.7.2/proxy/trojan/server.go:335 +0x5cb
github.com/xtls/xray-core/proxy/trojan.(*Server).Process(0xc001530d50, {0x3690098, 0xc0012d5e90}, 0x36498d8?, {0x36a00a8?, 0xc0012d5da0}, {0x3694540, 0xc0014e9ad0})
        github.com/xtls/xray-core@v1.7.2/proxy/trojan/server.go:235 +0x1b0d
github.com/xtls/xray-core/app/proxyman/inbound.(*tcpWorker).callback(0xc0014ef7c0, {0x36a00a8, 0xc0012d5da0})
        github.com/xtls/xray-core@v1.7.2/app/proxyman/inbound/worker.go:107 +0x6c3
created by github.com/xtls/xray-core/app/proxyman/inbound.(*tcpWorker).Start.func1
        github.com/xtls/xray-core@v1.7.2/app/proxyman/inbound/worker.go:121 +0x98
xrayr.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
xrayr.service: Failed with result 'exit-code'.
xrayr.service: Scheduled restart job, restart counter is at 14.

my config:

Log:
  Level: warning # Log level: none, error, warning, info, debug
  AccessPath: /opt/XrayR/logs/access.log
  ErrorPath: /opt/XrayR/logs/error.log

DnsConfigPath: /opt/XrayR/config/dns.json # Path to dns config, check https://xtls.github.io/config/dns.html for help
RouteConfigPath: /opt/XrayR/config/route.json # Path to route config, check https://xtls.github.io/config/routing.html for help
InboundConfigPath: # /opt/XrayR/config/custom_inbound.json # Path to custom inbound config, check https://xtls.github.io/config/inbound.html for help
OutboundConfigPath: /opt/XrayR/config/custom_outbound.json # Path to custom outbound config, check https://xtls.github.io/config/outbound.html for help

ConnectionConfig:
  Handshake: 4 # Handshake time limit, Second
  ConnIdle: 30 # Connection idle time limit, Second
  UplinkOnly: 2 # Time limit when the connection downstream is closed, Second
  DownlinkOnly: 4 # Time limit when the connection is closed after the uplink is closed, Second
  BufferSize: 64 # The internal cache size of each connection, kB

Nodes:
  - PanelType: "PMpanel" # Panel type: SSpanel, V2board, NewV2board, PMpanel, Proxypanel, V2RaySocks

    ApiConfig:
      ApiHost: https://example.org/webapi
      ApiKey: 123456
      NodeID: 1
      NodeType: Trojan # Node type: V2ray, Shadowsocks, Trojan
      Timeout: 30 # Timeout for the api request
      EnableVless: false # Enable Vless for V2ray Type
      EnableXTLS: false # Enable XTLS for V2ray and Trojan
      SpeedLimit: 0 # Mbps, Local settings will replace remote settings
      DeviceLimit: 0 # Local settings will replace remote settings
      RuleListPath: /opt/XrayR/config/rulelist # Path to local rulelist file

    ControllerConfig:
      ListenIP: 127.0.0.1 # IP address you want to listen
      SendIP: 0.0.0.0 # IP address you want to send pacakage
      UpdatePeriodic: 10 # Time to update the nodeinfo, how many sec.
      EnableDNS: true # Use custom DNS config, Please ensure that you set the dns.json well
      DNSType: AsIs # AsIs, UseIP, UseIPv4, UseIPv6, DNS strategy
      DisableUploadTraffic: false # Disable Upload Traffic to the panel
      DisableGetRule: false # Disable Get Rule from the panel
      DisableIVCheck: false # Disable the anti-reply protection for Shadowsocks
      DisableSniffing: false # Disable domain sniffing
      EnableProxyProtocol: true # Only works for WebSocket and TCP

      AutoSpeedLimitConfig:
        Limit: 0 # Warned speed. Set to 0 to disable AutoSpeedLimit (mbps)
        WarnTimes: 0 # After (WarnTimes) consecutive warnings, the user will be limited. Set to 0 to punish overspeed user immediately.
        LimitSpeed: 0 # The speedlimit of a limited user (unit: mbps)
        LimitDuration: 0 # How many minutes will the limiting last (unit: minute)

      GlobalDeviceLimitConfig:
        Enable: true # Enable the global device limit of a user
        RedisAddr: 1.1.1.1:6379 # The redis server address
        RedisPassword: 123456 # Redis password
        RedisDB: 0 # Redis DB
        Timeout: 5 # Timeout for redis request
        Expiry: 60 # Expiry time (second)

      EnableFallback: true # Only support for Trojan and Vless
      FallBackConfigs: # Support multiple fallbacks
        - SNI: # TLS SNI(Server Name Indication), Empty for any
          Alpn: # Alpn, Empty for any
          Path: # HTTP PATH, Empty for any
          Dest: 80 # Required, Destination of fallback, check https://xtls.github.io/config/fallback/ for details.
          ProxyProtocolVer: 0 # Send PROXY protocol version, 0 for dsable

      CertConfig:
        CertMode: none # Option about how to get certificate: none, file, http, dns
        RejectUnknownSni: false # Reject unknown SNI
        CertDomain: uk1.example.org # Domain to cert (fill in if want xrary issue certificate)
        CertFile: /opt/certificates/xrayr.crt # Provided if the CertMode is file
        KeyFile: /opt/certificates/xrayr.key
        Provider: cloudflare # DNS cert provider, Get the full support list here: https://go-acme.github.io/lego/dns/
        Email: mmokhtarabadi@gmail.com

        DNSEnv: # DNS ENV option used by DNS provider
          CLOUDFLARE_EMAIL: 123456789@gmail.com
          CLOUDFLARE_API_KEY: api_key_here

the problem does not appear in version v0.8.3

I think this is xtls bug

mokhtarabadi commented 1 year ago

@pocketW @thank243, the bug appears in version 0.8.3, but is very lower than in the latest version, for example, a crash occurs every 1 minute in the latest version but in 0.8.3 it occurs every 40-60 minutes

Jan 13 08:56:36 systemd[1]: Started xrayr Service.
Jan 13 08:56:37 XrayR[16469]: XrayR 0.8.3 (A Xray backend that supports many panels)
Jan 13 08:56:37 XrayR[16469]: 2023/01/13 08:56:37 Start the panel..
Jan 13 08:56:37 XrayR[16469]: 2023/01/13 08:56:37 Xray Core Version: 1.5.10
Jan 13 08:56:37 XrayR[16469]: 2023/01/13 08:56:37 [Trojan: 3] Added 98 new users
Jan 13 08:56:37 XrayR[16469]: 2023/01/13 08:56:37 [Trojan: 3] Start monitor node status
Jan 13 08:56:37 XrayR[16469]: 2023/01/13 08:56:37 [Trojan: 3] Start report node status
Jan 13 08:56:38 XrayR[16469]: panic: runtime error: invalid memory address or nil pointer dereference
Jan 13 08:56:38 XrayR[16469]: [signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x6f3e40]
Jan 13 08:56:38 XrayR[16469]: goroutine 886 [running]:
Jan 13 08:56:38 XrayR[16469]: github.com/xtls/xray-core/transport/internet/udp.(*Dispatcher).Dispatch(0xc000be6ba0?, {0x24da358, 0xc000be1680}, {{0x24dc150?, 0xc000b61d58?}, 0x6b40?, 0xc0?}, 0xc000be1650)
Jan 13 08:56:38 XrayR[16469]:         github.com/xtls/xray-core@v1.5.10/transport/internet/udp/dispatcher.go:86 +0x1e0
Jan 13 08:56:38 XrayR[16469]: github.com/xtls/xray-core/proxy/trojan.(*Server).handleUDPPayload(0xc001086d80, {0x24da358, 0xc000990a80}, 0x0?, 0xc000be15c0, {0x24dd880?, 0xc001045690})
Jan 13 08:56:38 XrayR[16469]:         github.com/xtls/xray-core@v1.5.10/proxy/trojan/server.go:335 +0x5cb
Jan 13 08:56:38 XrayR[16469]: github.com/xtls/xray-core/proxy/trojan.(*Server).Process(0xc001086d80, {0x24da358, 0xc000990a80}, 0x24b7f80?, {0x24e6258?, 0xc0009909f0}, {0x24dd880, 0xc001045690})
Jan 13 08:56:38 XrayR[16469]:         github.com/xtls/xray-core@v1.5.10/proxy/trojan/server.go:235 +0x1aed
Jan 13 08:56:38 XrayR[16469]: github.com/xtls/xray-core/app/proxyman/inbound.(*tcpWorker).callback(0xc00108c280, {0x24e6258, 0xc0009909f0})
Jan 13 08:56:38 XrayR[16469]:         github.com/xtls/xray-core@v1.5.10/app/proxyman/inbound/worker.go:107 +0x6c3
Jan 13 08:56:38 XrayR[16469]: created by github.com/xtls/xray-core/app/proxyman/inbound.(*tcpWorker).Start.func1
Jan 13 08:56:38 XrayR[16469]:         github.com/xtls/xray-core@v1.5.10/app/proxyman/inbound/worker.go:121 +0x98
Jan 13 08:56:38 systemd[1]: xrayr.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Jan 13 08:56:38 systemd[1]: xrayr.service: Failed with result 'exit-code'.
Jan 13 08:56:49 systemd[1]: xrayr.service: Scheduled restart job, restart counter is at 68.
Jan 13 08:56:49 systemd[1]: Stopped xrayr Service.
Jan 13 08:56:49 systemd[1]: Started xrayr Service.
Jan 13 08:56:49 XrayR[16490]: XrayR 0.8.3 (A Xray backend that supports many panels)
Jan 13 08:56:49 XrayR[16490]: 2023/01/13 08:56:49 Start the panel..
Jan 13 08:56:49 XrayR[16490]: 2023/01/13 08:56:49 Xray Core Version: 1.5.10
MrVb0 commented 1 year ago

Ever since I set the global device limit to "false" and set the device limit to "0" and completely removed the speed limit in v2board (set it to 0), I feel that the disconnection and problems have decreased a lot. I felt that maybe telling you this will help you solve it. Thanks

pocketW commented 1 year ago

Thanks for your guys reporting the details. Just to check. Are you all using the Trojan? Does this bug also happen to other protocols like Shadowsocks and VMESS? I found all the logs saying this bug happened when using the Trojan.

MrVb0 commented 1 year ago

I have both trojan and vmess on all my servers and I don't know which one is the problem . Thanks

mokhtarabadi commented 1 year ago

@pocketW I used only the Trojan protocol, and I don't know about vmess or others, Thank you too

MrVb0 commented 1 year ago

In the past few days, I did different tests to find the main fault. First of all, I set the "global device limit" to "false" and set the "device limit" to "0" and completely removed the "speed limit" (set it to 0) After this, as far as I checked, this error was no longer observed and disconnection and disconnection became much less. So the problem is one of these things!

So I tested one by one:

In the first step, I set "Device limit" to "2", (while "Global device limit" was still "false") No error was observed at this stage.

In the second step, I set "Speed limit" to "100", No error was observed at this stage either.

In the next step, I set "Global device limit" to "true" again! And after a few seconds and a few "warnings" about device limitations, this error appeared again!!

According to my research, I am sure that "Global Device Limit" directly or indirectly causes this error. But I really need this feature and I am asking you to "please" solve this problem, thank you very much.

mokhtarabadi commented 1 year ago

I understand increasing device limit locally means in xrayr config will fix problem for a long time, until one user reaches the limitation, even when global device limit is enabled

pocketW commented 1 year ago

Thanks for your guys' responses. After analyzing, I found this error is related to a bug in Xray-core handling UDP packages. I have raised a PR to fix this problem XTLS/Xray-core#1542.

Septrum101 commented 1 year ago

Thanks for your guys' responses. After analyzing, I found this error is related to a bug in Xray-core handling UDP packages. I have raised a PR to fix this problem XTLS/Xray-core#1542.

Good jobs.

MrVb0 commented 1 year ago

Thanks for your guys' responses. After analyzing, I found this error is related to a bug in Xray-core handling UDP packages. I have raised a PR to fix this problem XTLS/Xray-core#1542.

Excellent, thank you Does this mean that this case is not related to the global device limit?

mokhtarabadi commented 1 year ago

Thanks for your guys' responses. After analyzing, I found this error is related to a bug in Xray-core handling UDP packages. I have raised a PR to fix this problem XTLS/Xray-core#1542.

Thank you man, I'll check it

MrVb0 commented 1 year ago

Thanks for your guys' responses. After analyzing, I found this error is related to a bug in Xray-core handling UDP packages. I have raised a PR to fix this problem XTLS/Xray-core#1542.

Thank you man, I'll check it

Can you guide me how to update to master branch?

mokhtarabadi commented 1 year ago

Thanks for your guys' responses. After analyzing, I found this error is related to a bug in Xray-core handling UDP packages. I have raised a PR to fix this problem XTLS/Xray-core#1542.

Thank you man, I'll check it

Can you guide me how to update to master branch?

Clone xray-core repository, apply the @pocketW PR, in XrayR add a link to your xray-core instead original version, and then build XrayR or send me a PM in telegram I'll send my built

MrVb0 commented 1 year ago

Thanks for your guys' responses. After analyzing, I found this error is related to a bug in Xray-core handling UDP packages. I have raised a PR to fix this problem XTLS/Xray-core#1542.

Hello Thank you for your efforts to resolve this issue But unfortunately, after updating to the new version (19583503cddf56398384472e0ffa9648ca67eb94) if Global device limit is on, after receiving a few ( [Warning] Devices reach the limit ) I still encounter the following error:

Jan 21 22:37:51 new-xrayr XrayR[1640]: 2023/01/21 22:37:51 [Warning] Devices reach the limit: Trojan_127.0.0.1_20524|1a452b2-0b2f-48ed-b1g5-fd116f39d788@v2board.user|35
Jan 21 22:37:51 new-xrayr XrayR[1640]: panic: runtime error: invalid memory address or nil pointer dereference
Jan 21 22:37:51 new-xrayr XrayR[1640]: [signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x938de0]
Jan 21 22:37:51 new-xrayr XrayR[1640]: goroutine 20538 [running]:
Jan 21 22:37:51 new-xrayr XrayR[1640]: github.com/xtls/xray-core/transport/internet/udp.(*Dispatcher).Dispatch(0xc002b9da40?, {0x368a738, 0xc002f1bb30}, {{0x368c878?, 0xc00244d8d0?}, 0xd9e0?, 0xc0?}, 0xc002f1bb00)
Jan 21 22:37:51 new-xrayr XrayR[1640]: github.com/xtls/xray-core@v1.7.2/transport/internet/udp/dispatcher.go:86 +0x1e0
Jan 21 22:37:51 new-xrayr XrayR[1640]: github.com/xtls/xray-core/proxy/trojan.(*Server).handleUDPPayload(0xc0009d7f20, {0x368a738, 0xc002f1b9b0}, 0x0?, 0xc002f1ba70, {0x368ebe0?, 0xc000cc35d0})
Jan 21 22:37:51 new-xrayr XrayR[1640]: github.com/xtls/xray-core@v1.7.2/proxy/trojan/server.go:335 +0x5cb
Jan 21 22:37:51 new-xrayr XrayR[1640]: github.com/xtls/xray-core/proxy/trojan.(*Server).Process(0xc0009d7f20, {0x368a738, 0xc002f1b9b0}, 0x3643fb0?, {0x7fd0d1bcad18?, 0xc00012efc0}, {0x368ebe0, 0xc000cc35d0})
Jan 21 22:37:51 new-xrayr XrayR[1640]: github.com/xtls/xray-core@v1.7.2/proxy/trojan/server.go:235 +0x1b0d
Jan 21 22:37:51 new-xrayr XrayR[1640]: github.com/xtls/xray-core/app/proxyman/inbound.(*tcpWorker).callback(0xc000cacdc0, {0x7fd0d1bcad18, 0xc00012efc0})
Jan 21 22:37:51 new-xrayr XrayR[1640]: github.com/xtls/xray-core@v1.7.2/app/proxyman/inbound/worker.go:107 +0x6c3
Jan 21 22:37:51 new-xrayr XrayR[1640]: created by github.com/xtls/xray-core/app/proxyman/inbound.(*tcpWorker).Start.func1
Jan 21 22:37:51 new-xrayr XrayR[1640]: github.com/xtls/xray-core@v1.7.2/app/proxyman/inbound/worker.go:121 +0x98
Jan 21 22:37:51 new-xrayr systemd[1]: XrayR.service: main process exited, code=exited, status=2/INVALIDARGUMENT
Jan 21 22:37:51 new-xrayr systemd[1]: Unit XrayR.service entered failed state.
Jan 21 22:37:51 new-xrayr systemd[1]: XrayR.service failed.
Jan 21 22:38:01 new-xrayr systemd[1]: XrayR.service holdoff time over, scheduling restart.
Jan 21 22:38:01 new-xrayr systemd[1]: Stopped XrayR Service.
Jan 21 22:38:01 new-xrayr systemd[1]: Started XrayR Service.
Jan 21 22:38:01 new-xrayr XrayR[1650]: XrayR 0.8.8 (A Xray backend that supports many panels)
Jan 21 22:38:01 new-xrayr XrayR[1650]: 2023/01/21 22:38:01 Start the panel..
Jan 21 22:38:01 new-xrayr XrayR[1650]: 2023/01/21 22:38:01 Xray Core Version: 1.7.2
Jan 21 22:38:01 new-xrayr XrayR[1650]: 2023/01/21 22:38:01 [Warning] core: Xray 1.7.2 started
Jan 21 22:38:01 new-xrayr XrayR[1650]: 2023/01/21 22:38:01 [Warning] transport/internet/tcp: accepting PROXY protocol
MrVb0 commented 1 year ago

One thing I just noticed: In addition to v2board, I also used sspanel One of my Xrayr servers is connected to sspanel. As you know, the global device limit feature is also available in sspanel When I updated the xrayr server that was connected to sspanel to version 0.8.8, I immediately encountered the same error!!! (invalid memory address or nil pointer dereference) And when I downgraded to the previous version (0.8.6) the problem was solved!

pocketW commented 1 year ago

Thanks for your guys' responses. After analyzing, I found this error is related to a bug in Xray-core handling UDP packages. I have raised a PR to fix this problem XTLS/Xray-core#1542.

Hello Thank you for your efforts to resolve this issue But unfortunately, after updating to the new version (19583503cddf56398384472e0ffa9648ca67eb94) if Global device limit is on, after receiving a few ( [Warning] Devices reach the limit ) I still encounter the following error:

Jan 21 22:37:51 new-xrayr XrayR[1640]: 2023/01/21 22:37:51 [Warning] Devices reach the limit: Trojan_127.0.0.1_20524|1a452b2-0b2f-48ed-b1g5-fd116f39d788@v2board.user|35
Jan 21 22:37:51 new-xrayr XrayR[1640]: panic: runtime error: invalid memory address or nil pointer dereference
Jan 21 22:37:51 new-xrayr XrayR[1640]: [signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x938de0]
Jan 21 22:37:51 new-xrayr XrayR[1640]: goroutine 20538 [running]:
Jan 21 22:37:51 new-xrayr XrayR[1640]: github.com/xtls/xray-core/transport/internet/udp.(*Dispatcher).Dispatch(0xc002b9da40?, {0x368a738, 0xc002f1bb30}, {{0x368c878?, 0xc00244d8d0?}, 0xd9e0?, 0xc0?}, 0xc002f1bb00)
Jan 21 22:37:51 new-xrayr XrayR[1640]: github.com/xtls/xray-core@v1.7.2/transport/internet/udp/dispatcher.go:86 +0x1e0
Jan 21 22:37:51 new-xrayr XrayR[1640]: github.com/xtls/xray-core/proxy/trojan.(*Server).handleUDPPayload(0xc0009d7f20, {0x368a738, 0xc002f1b9b0}, 0x0?, 0xc002f1ba70, {0x368ebe0?, 0xc000cc35d0})
Jan 21 22:37:51 new-xrayr XrayR[1640]: github.com/xtls/xray-core@v1.7.2/proxy/trojan/server.go:335 +0x5cb
Jan 21 22:37:51 new-xrayr XrayR[1640]: github.com/xtls/xray-core/proxy/trojan.(*Server).Process(0xc0009d7f20, {0x368a738, 0xc002f1b9b0}, 0x3643fb0?, {0x7fd0d1bcad18?, 0xc00012efc0}, {0x368ebe0, 0xc000cc35d0})
Jan 21 22:37:51 new-xrayr XrayR[1640]: github.com/xtls/xray-core@v1.7.2/proxy/trojan/server.go:235 +0x1b0d
Jan 21 22:37:51 new-xrayr XrayR[1640]: github.com/xtls/xray-core/app/proxyman/inbound.(*tcpWorker).callback(0xc000cacdc0, {0x7fd0d1bcad18, 0xc00012efc0})
Jan 21 22:37:51 new-xrayr XrayR[1640]: github.com/xtls/xray-core@v1.7.2/app/proxyman/inbound/worker.go:107 +0x6c3
Jan 21 22:37:51 new-xrayr XrayR[1640]: created by github.com/xtls/xray-core/app/proxyman/inbound.(*tcpWorker).Start.func1
Jan 21 22:37:51 new-xrayr XrayR[1640]: github.com/xtls/xray-core@v1.7.2/app/proxyman/inbound/worker.go:121 +0x98
Jan 21 22:37:51 new-xrayr systemd[1]: XrayR.service: main process exited, code=exited, status=2/INVALIDARGUMENT
Jan 21 22:37:51 new-xrayr systemd[1]: Unit XrayR.service entered failed state.
Jan 21 22:37:51 new-xrayr systemd[1]: XrayR.service failed.
Jan 21 22:38:01 new-xrayr systemd[1]: XrayR.service holdoff time over, scheduling restart.
Jan 21 22:38:01 new-xrayr systemd[1]: Stopped XrayR Service.
Jan 21 22:38:01 new-xrayr systemd[1]: Started XrayR Service.
Jan 21 22:38:01 new-xrayr XrayR[1650]: XrayR 0.8.8 (A Xray backend that supports many panels)
Jan 21 22:38:01 new-xrayr XrayR[1650]: 2023/01/21 22:38:01 Start the panel..
Jan 21 22:38:01 new-xrayr XrayR[1650]: 2023/01/21 22:38:01 Xray Core Version: 1.7.2
Jan 21 22:38:01 new-xrayr XrayR[1650]: 2023/01/21 22:38:01 [Warning] core: Xray 1.7.2 started
Jan 21 22:38:01 new-xrayr XrayR[1650]: 2023/01/21 22:38:01 [Warning] transport/internet/tcp: accepting PROXY protocol

The PR has not been merged into the Xray-core. We will update the fix once it has been merged. The current commit does not fix this issue. Besides, you can also fork my PR in Xray-core and replace the dependencies with it to test.

mokhtarabadi commented 1 year ago

After many testing I didn't see the crash anymore with the global device limit enabled, it fixed with @pocketW PR Also in logs, I see many device limit warnings, but no crash

pocketW commented 1 year ago

After many testing I didn't see the crash anymore with the global device limit enabled, it fixed with @pocketW PR Also in logs, I see many device limit warnings, but no crash

Good to hear that! Thanks for testing.

MrVb0 commented 1 year ago

It is absolutely true, I did this with the help of my good friend @mokhtarabadi, no error was found. Thank you very much, your work was great. @pocketW

pocketW commented 1 year ago

fixed at a7a3d0220de2e088c7b0dd602de4846a4ac11a16