URL testing stops with error "panic: runtime error: invalid memory address"

[AnFlare]

Operating system

Windows

System version

Windows 11 Pro, 25H2, 26200.7623

Installation type

zip

Version

1.0.13

Description

Servers' URL testing stops testing with the error "panic: runtime error: invalid memory address or nil pointer dereference"

Reproduction

1. Download and start fresh Throne-1.0.13-windows64.zip
2. Insert 2 address below (I found URL testing crashes during these)

vless://224162a4-659e-4644-9cb4-8024c6dda3c5@162.159.152.4:2096?encryption=none&security=tls&sni=%F0%9F%94%92%20[By%20EbraSha]%201146%20%7C%20Bah-04%7C%20MTSRVRS%20&alpn=h3,h2,http/1.1&fp=chrome&type=xhttp&path=%F0%9F%94%92%20[By%20EbraSha]&mode=auto&packetEncoding=xudp#%20%F0%9F%94%92%20[By%20EbraSha]
vless://22e7f0d3-8d3b-40c7-a1c5-8a912f6a16b3@8.6.112.0:443?encryption=none&security=tls&sni=%F0%9F%94%92%20[By%20EbraSha]%20&type=ws&host=cdn.55994421.xyz&path=%F0%9F%94%92%20[By%20EbraSha]&packetEncoding=xudp#%20%F0%9F%94%92%20[By%20EbraSha]

3. Select them and in context menu choose "URL Test Selected"

Logs

2026/02/07 17:48:34 [restoreSystemDNS] no action needed
sing-box: v1.12.14
Core listening at 127.0.0.1:56470
INFO[0000] network: updated default interface Wi-Fi, index 3
INFO[0000] sing-box started (0.11s)
INFO[0000] outbound/vless[proxy-1-0]: outbound connection to cp.cloudflare.com:80
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x1 addr=0x68 pc=0x7ff6e3dbd1aa]

goroutine 67 [running]:
github.com/sagernet/sing-box/option.(*V2RayXHTTPBaseOptions).GetRequestHeader(0xc00005bc80, {0xc000102200, 0x92})
	github.com/sagernet/sing-box@v1.12.14/option/v2ray_transport.go:185 +0x20a
github.com/sagernet/sing-box/transport/v2rayxhttp.(*DefaultDialerClient).OpenStream(0xc0004cc0c0, {0x7ff6e52ea610, 0xc00019ac60}, {0xc000102200, 0x92}, {0x0, 0x0}, 0x0)
	github.com/sagernet/sing-box@v1.12.14/transport/v2rayxhttp/dialer.go:61 +0x255
github.com/sagernet/sing-box/transport/v2rayxhttp.(*Client).DialContext(0xc0000a7540, {0x7ff6e52ea610, 0xc00019ac60})
	github.com/sagernet/sing-box@v1.12.14/transport/v2rayxhttp/client.go:205 +0x6c4
github.com/sagernet/sing-box/protocol/vless.(*vlessDialer).DialContext(0xc000264460, {0x7ff6e52ea648?, 0xc0004d7180?}, {0x7ff6e4f9c520, 0x3}, {{{0x0, 0x0}, {0x0}}, 0x50, {0xc000040180, ...}})
	github.com/sagernet/sing-box@v1.12.14/protocol/vless/outbound.go:142 +0x135
github.com/sagernet/sing-box/protocol/vless.(*Outbound).DialContext(0xc000264460, {0x7ff6e52ea648, 0xc0004d7180}, {0x7ff6e4f9c520, 0x3}, {{{0x0, 0x0}, {0x0}}, 0x50, {0xc000040180, ...}})
	github.com/sagernet/sing-box@v1.12.14/protocol/vless/outbound.go:98 +0x5ee
main.BatchURLTest.func1.1({0xc0004f99f0?, 0x7ff6e388c285?}, {0x118?, 0x7ff6e4f64840?}, {0xc000040180?, 0xc0004f9a18?})
	Core/test_utils.go:141 +0xca
net/http.(*Transport).dial(0xc0004d84e0?, {0x7ff6e52ea648?, 0xc0004d76d0?}, {0x7ff6e4f9c520?, 0x7ff6e3922319?}, {0xc000040180?, 0xc0004f9a80?})
	net/http/transport.go:1278 +0xd2
net/http.(*Transport).dialConn(0xc0004d84e0, {0x7ff6e52ea648, 0xc0004d76d0}, {{}, 0x0, {0xc0004a2800, 0x4}, {0xc000040180, 0x14}, 0x0})
	net/http/transport.go:1783 +0x7e5
net/http.(*Transport).dialConnFor(0xc0004d84e0, 0xc00034c580)
	net/http/transport.go:1618 +0xb8
net/http.(*Transport).startDialConnForLocked.func1()
	net/http/transport.go:1600 +0x35
created by net/http.(*Transport).startDialConnForLocked in goroutine 66
	net/http/transport.go:1599 +0x112
[Error] Core: LibcoreService error: protorpc.RecvResponseHeader: RecvFrame failed.
[Fatal] Core exited, cleaning up...
URL test finished!
[Warn] Restarting the core ...
2026/02/07 17:48:38 [restoreSystemDNS] no action needed
sing-box: v1.12.14
Core listening at 127.0.0.1:56470

[AnFlare]

Found a bunch of others that provoke the same behaviour:

vless://1bbf3b87-5f9d-4358-8a40-3cf9ab65332c@zula.ir:8443?encryption=none&security=tls&sni=%F0%9F%94%92%20[By%20EbraSha]%20&alpn=h3&fp=chrome&type=xhttp&host=Main.kasler.lol&path=%F0%9F%94%92%20[By%20EbraSha]&mode=auto&packetEncoding=xudp#%20%F0%9F%94%92%20[By%20EbraSha]
vless://2ce48b7b-6271-4dae-b894-2a58bf382787@frx.fastdbn.com:443?encryption=none&security=reality&sni=%F0%9F%94%92%20[By%20EbraSha]%20&fp=chrome&pbk=12UHjWCU_BNIkRmxt-6QKAuVuSIFzoS2jkN1BIMzGjM&sid=&type=xhttp&path=/&mode=auto&packetEncoding=xudp#%20%F0%9F%94%92%20[By%20EbraSha]
vless://0e42d744-1079-40ef-a5e6-968f5e78e0a4@91.107.254.202:2096?encryption=none&security=reality&sni=%F0%9F%94%92%20[By%20EbraSha]&fp=chrome&pbk=sPEQ8mlkuJQsGrMZux2g9EmXKztuXHwnyORJPwwznDQ&sid=a0e13102&type=xhttp&host=firebase.googleapis.com&path=%F0%9F%94%92%20[By%20EbraSha]&mode=auto&packetEncoding=xudp#%20%F0%9F%94%92%20[By%20EbraSha]
vless://0dbad6ba-be87-46e1-ab90-30c53ef1878d@chatgpt.com:443?encryption=none&security=tls&sni=%F0%9F%94%92%20[By%20EbraSha]%20&alpn=h2&fp=chrome&type=xhttp&path=%F0%9F%94%92%20[By%20EbraSha]&mode=auto&packetEncoding=xudp#%20%F0%9F%94%92%20[By%20EbraSha]
vless://0dbad6ba-be87-46e1-ab90-30c53ef1878d@chatgpt.com:443?encryption=none&security=tls&sni=%F0%9F%94%92%20[By%20EbraSha]%201128%20%7C%20Bah-04%7C%20MTSRVRS%20&alpn=h2&fp=chrome&type=xhttp&path=%F0%9F%94%92%20[By%20EbraSha]&mode=auto&packetEncoding=xudp#%20%F0%9F%94%92%20[By%20EbraSha]
vless://1bbf3b87-5f9d-4358-8a40-3cf9ab653388@zula.ir:8443?encryption=none&security=tls&sni=%F0%9F%94%92%20[By%20EbraSha]%20&alpn=h3,h2,http/1.1&fp=chrome&type=xhttp&host=har.harchi.monster&path=%F0%9F%94%92%20[By%20EbraSha]&mode=auto&packetEncoding=xudp#%20%F0%9F%94%92%20[By%20EbraSha]
vless://0dbad6ba-be87-46e1-ab90-30c53ef1878d@50.7.4.107:443?encryption=none&security=tls&sni=%F0%9F%94%92%20[By%20EbraSha]&alpn=h2%20&fp=chrome&type=xhttp&path=%F0%9F%94%92%20[By%20EbraSha]&mode=auto&packetEncoding=xudp#%20%F0%9F%94%92%20[By%20EbraSha]

[Mahdi-zarei]

The crash is caused by poor safeguards, but the configs are already broken anyways

What kind of Path or SNI is that?

[AnFlare]

@Mahdi-zarei
Ok, understood, thank you!! These addresses are from the whole internet, so they really can be malformed...
I made a "Remove Invalid" test before, but it did nothing. Is it supposed to to filter out configs like this?

[Mahdi-zarei]

@Mahdi-zarei Ok, understood, thank you!! These addresses are from the whole internet, so they really can be malformed... I made a "Remove Invalid" test before, but it did nothing. Is it supposed to to filter out configs like this?

Remove invalid is not yet implemented for Xray configs, but it will be soon. Though if Xray still crashes when given a malformed config, it may not work either.