Proxy Protocols · Clash documentation

ShadowsocksR (SSR)

Configure ShadowsocksR outbound proxies in the Clash ecosystem using current Mihomo fields, including stream ciphers, Protocol, Obfs, and compatibility limits for legacy nodes.

  • cipher
  • protocol
  • protocol-param
  • obfs
  • udp
Proxy Protocols

Configuration differences between SSR and Shadowsocks

ShadowsocksR is a compatibility outbound type for legacy SSR servers. The client applies SSR obfuscation, stream encryption, and the SSR Protocol in sequence, so the configuration includes more than the SS cipher and password.

For an existing SSR node, use the complete fields supplied by the server or a trusted subscription. You cannot turn a modern Shadowsocks node into SSR simply by changing type .

Minimum required fields

In addition to the common address fields, an SSR node must provide a password, stream cipher, obfuscation method, and SSR Protocol.

nameRequired
The node name, which must be unique within the current configuration.
typeRequired
Set this to ssr
serverRequired
The domain name or IP address of the SSR server.
portRequired
The SSR server's listening port.
cipherRequired
The stream cipher used by SSR. It must match the server.
passwordRequired
The SSR node password.
obfsRequired
The SSR obfuscation name, which controls how the connection appears.
protocolRequired
The SSR Protocol name, which controls authentication and data framing.

Cipher, Obfs, and Protocol must match as a set

The current SSR implementation accepts supported stream ciphers and is also compatible with nonenone , which it processes internally as dummy . Modern SS AEAD ciphers cannot be used directly with SSR.

Responsibilities of core SSR fields
FieldPurposeConfiguration requirement
cipherEncrypts the SSR data streamUse the stream cipher supplied by the SSR server; do not replace it with an AEAD name
passwordDerives the encryption keyMust exactly match the current SSR node password
obfsControls the connection's traffic profileThe name must be supported by the server
protocolHandles authentication and packet framingThe name must be supported by the server

Parameters, UDP, and common connection options

Provide parameter fields only when required by the corresponding server configuration. Preserve all parameters supplied by a subscription; do not infer them from another SSR node.

obfs-paramOptional
Parameters passed to the SSR obfuscation module. Typical contents depend on the server configuration.
protocol-paramOptional
Parameters passed to the SSR Protocol. Preserve the format required by the server.
udpOptional
Allows the node to handle UDP. The server, Protocol, and network must support it as well.
ip-versionOptional
Controls whether a domain-form server address uses IPv4, IPv6, or dual stack.
dialer-proxyOptional
Connects to the SSR server through another node or policy group.
  • SSR nodes do not have the Shadowsocks plugin and plugin-opts field.
  • SSR nodes also have no protocol-level top-level TLS field. Do not add tls: true
  • The UDP switch cannot fix an incorrect cipher, obfs, or protocol combination.

SSR node example and troubleshooting

This example shows the base fields from the official configuration. If the server also supplies obfs-param or protocol-param, append it at the same level.

  • If cipher initialization fails, confirm that you are using a stream cipher supported by SSR.
  • If the node connects but cannot transfer data, first verify protocol and protocol-param
  • If the handshake's traffic profile does not match, verify obfsobfs-param as well as the server address and port.
YAML
proxies:
  - name: ssr-node
    type: ssr
    server: server.example.com
    port: 443
    cipher: chacha20-ietf
    password: your-password
    protocol: auth_sha1_v4
    obfs: tls1.2_ticket_auth