[Bug] The transport section of the configuration file is not working properly

[hooUmAi]

Now we have these two sample client and server configuration files:
client.json:

{
        "log": {
                "loglevel": "debug"
        },
        "inbounds": [
                {
                        "listen": "127.0.0.1",
                        "port": 9089,
                        "protocol": "socks"
                }
        ],
        "outbounds": [{
                "protocol": "vless",
                "settings": {
                        "vnext": [{
                                "address": "127.0.0.1",
                                "port": 9090,
                                "users": [{
                                        "id": "5783a3e7-e373-51cd-8642-c83782b807c5",
                                        "encryption": "none"
                                }]
                        }]
                },
                "streamSettings":  {
                        //"grpcSettings": {
                        //        "serviceName": "test1",
                        //        "user_agent": "test2"
                        //},
                        "network": "grpc",
                        "security": "none"
                }
        }],
        "transport": {
                "grpcSettings": {
                        "serviceName": "test1",
                        "user_agent": "test2"
                }
        }
}

server.json:

{
        "log": {
                "loglevel": "debug"
        },
        "outbounds": [
                {
                        "protocol": "freedom"
                }
        ],
        "inbounds": [{
                "listen": "127.0.0.1",
                "port": 9091,
                "protocol": "vless",
                "settings": {
                        "clients": [{
                                "id": "5783a3e7-e373-51cd-8642-c83782b807c5"
                        }],
                        "decryption": "none"
                },
                "streamSettings":  {
                        //"grpcSettings": {
                        //        "serviceName": "test1"
                        //},
                        "network": "grpc",
                        "security": "none"
                }
        }],
        "transport": {
                "grpcSettings": {
                        "serviceName": "test1"
                }
        }
}

I have placed a caddy between the client and the server in order to record access logs with the following configuration file:
Caddyfile

{
        auto_https off
        servers {
                protocols h1 h2 h2c h3
        }
}
http://127.0.0.1:9090 {
        log
        @grpc {
                protocol grpc
                path /test1*
        }
        reverse_proxy @grpc h2c://127.0.0.1:9091
}

According to the documentation:

Generally speaking the client and the server need to use the same transport method for inbound and outbound correspondences. When its configuration specifies a transport method but does not fill in the specific settings, this transport method will use the settings in the global configuration.

The configuration should function the same whether or not the grpcSettings part in the streamSettings contains the currently commented out content.

However, curl -x socks5h://127.0.0.1:9089 https://bing.com -v produces the following result:

*   Trying 127.0.0.1:9089...
* Connected to 127.0.0.1 (127.0.0.1) port 9089 (#0)
* SOCKS5 connect to bing.com:443 (remotely resolved)
* SOCKS5 request granted.
* Connected to 127.0.0.1 (127.0.0.1) port 9089 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to bing.com:443
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to bing.com:443

client log:

Xray 1.8.7 (Xray, Penetrates Everything.) 3f0bc13 (go1.21.5 linux/amd64)
A unified platform for anti-censorship.
2024/01/14 05:04:03 [Info] infra/conf/serial: Reading config: client.json
2024/01/14 05:04:03 [Debug] app/log: Logger started
2024/01/14 05:04:03 [Debug] app/proxyman/inbound: creating stream worker on 127.0.0.1:9089
2024/01/14 05:04:03 [Info] transport/internet/tcp: listening TCP on 127.0.0.1:9089
2024/01/14 05:04:03 [Warning] core: Xray 1.8.7 started
2024/01/14 05:04:18 [Info] [1901350633] proxy/socks: TCP Connect request to tcp:bing.com:443
2024/01/14 05:04:18 [Info] [1901350633] app/dispatcher: default route for tcp:bing.com:443
2024/01/14 05:04:18 tcp:127.0.0.1:53636 accepted tcp:bing.com:443
2024/01/14 05:04:18 [Info] [1901350633] transport/internet/grpc: creating connection to tcp:127.0.0.1:9090
2024/01/14 05:04:18 [Debug] transport/internet/grpc: using gRPC tun mode service name: `` stream name: `Tun`
2024/01/14 05:04:18 [Debug] transport/internet: dialing to tcp:127.0.0.1:9090
2024/01/14 05:04:18 [Info] [1901350633] proxy/vless/outbound: tunneling request to tcp:bing.com:443 via 127.0.0.1:9090
2024/01/14 05:04:18 [Info] [1901350633] app/proxyman/outbound: failed to process outbound traffic > proxy/vless/outbound: connection ends > proxy/vless/outbound: failed to decode response header > proxy/vless/encoding: failed to read response version > transport/internet/grpc/encoding: failed to fetch hunk from gRPC tunnel > rpc error: code = Unknown desc = malformed header: missing HTTP content-type
2024/01/14 05:04:18 [Info] [1901350633] app/proxyman/inbound: connection ends > proxy/socks: connection ends > proxy/socks: failed to transport all TCP response > io: read/write on closed pipe

server log:

Xray 1.8.7 (Xray, Penetrates Everything.) 3f0bc13 (go1.21.5 linux/amd64)
A unified platform for anti-censorship.
2024/01/14 05:04:07 [Info] infra/conf/serial: Reading config: server.json
2024/01/14 05:04:07 [Debug] app/log: Logger started
2024/01/14 05:04:07 [Debug] app/proxyman/inbound: creating stream worker on 127.0.0.1:9091
2024/01/14 05:04:07 [Warning] core: Xray 1.8.7 started
2024/01/14 05:04:07 [Debug] transport/internet/grpc: gRPC listen for service name `` tun `Tun` multi tun `TunMulti`

caddy log:

INFO    http.log.access handled request {"request": {"remote_ip": "127.0.0.1", "remote_port": "51560", "client_ip": "127.0.0.1", "proto": "HTTP/2.0", "method": "POST", "host": "127.0.0.1:9090", "uri": "//Tun", "headers": {"Content-Type": ["application/grpc"], "User-Agent": ["grpc-go/1.60.1"], "Te": ["trailers"]}}, "bytes_read": 0, "user_id": "", "duration": 0.000011111, "size": 0, "status": 0, "resp_headers": {"Server": ["Caddy"]}}

It looks like the grpcSettings in the transport section of both client.json and server.json are not taking effect.

When I remove the line comment tags on both sides, curl -x socks5h://127.0.0.1:9089 https://bing.com -v works as expected.

[yuhan6665]

yeah global transport is deprecated. Please don't use it

[hooUmAi]

A significant amount of my nodes use the same transport layer configuration, therefore this feature could significantly reduce the cost of maintaining configurations for similar usage scenarios. So why deliberately remove this existing feature?
Or is it possible to at least update the documentation to avoid causing more similar confusion?