config.json / outbounds excerpt
Subscriptions let you fetch connection profiles in bulk; groups help organize them by source in the client. Create a group, add the subscription URL, and update it. Then confirm the returned profiles can be parsed by your client. Check the node names, protocols, and transport fields—not just whether entries appear in the list. Group names and automatic update intervals are client settings, not universal core fields. The example below shows an outbound structure that might be generated after import. It contains no remote credentials and cannot establish a proxy connection on its own. To manage multiple sources, add filters while keeping the original groups.
{
"outbounds": [
{ "tag": "direct", "protocol": "freedom" },
{ "tag": "block", "protocol": "blackhole" }
]
}
config.json / routing
Routing rules determine which outbound handles traffic, usually in order of evaluation. Start with private addresses, add specific domain or IP rules, then check where unmatched traffic goes by default. Each rule’s outbound tag must exactly match a tag in the outbound list; otherwise, the rule may not work as expected. The example below sends private addresses to a direct outbound and requires the relevant geodata files. Unlike a global mode switch, rule-based routing can preserve local network access, but you also need to check when domains are resolved and how broadly each rule applies.
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}
]
}
}
config.json / log
Choose a core based on the connection parameters, not just the client’s name. Check the protocol, transport, and security layer, then confirm that the selected core supports those fields. Don’t assume another core can read the same configuration when core-specific extensions are involved. Save your settings before switching, then review the startup log and generated configuration to confirm which core is running. The log level below can help with initial troubleshooting; restore the previous level after temporarily enabling more detail. Runtime logs may include addresses and connection details, so remove sensitive information before sharing them.
{
"log": {
"loglevel": "warning"
}
}
config.json / inbounds / SOCKS
The system proxy only affects apps that honor the system proxy settings; it does not route all traffic. First verify the connection through a local proxy inbound, then decide whether you need TUN. TUN support depends on the client, supporting components, core, and system permissions—it isn’t enabled just by adding a switch to any configuration. The example below shows a SOCKS inbound listening on localhost for apps where you enter the proxy address manually; it is not a TUN configuration. When switching modes, check for conflicts with other proxy apps, virtual network adapters, and DNS settings that could create a traffic loop.
{
"inbounds": [
{
"tag": "local-socks",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": { "auth": "noauth", "udp": true }
}
]
}
config.json / dns
Check DNS at the application, system, and core levels. Adding a resolver in the client doesn’t mean every app’s queries will pass through the core. First find out where the domain is resolved, then check whether the resolver’s route depends on a proxy connection that hasn’t been established yet. The example below shows a basic setup that uses the local environment for resolution. It illustrates where fields go, but may not suit every network. If IP addresses work but domains do not, compare the DNS results with your routing policy. Simply changing resolvers may not help if DNS queries never reach the core.
{
"dns": {
"servers": ["localhost"]
},
"routing": {
"domainStrategy": "AsIs"
}
}
config.json / inbounds / LAN
Sharing with your local network requires the listening address, system firewall, and proxy settings on other devices to be configured correctly. If the client listens only on the loopback address, other devices can’t connect. If you listen on all interfaces, restrict which sources can connect. The example below shows part of an HTTP inbound configuration with authentication; the credentials are illustrative and must be changed before use. On other devices, enter the computer’s local network address, not its loopback address. Share only on trusted networks, and never expose the proxy port to the public internet. When you’re done, stop listening or switch back to local-only access.
{
"inbounds": [
{
"tag": "lan-http",
"listen": "0.0.0.0",
"port": 10809,
"protocol": "http",
"settings": {
"accounts": [
{ "user": "example-user", "pass": "your-password" }
]
}
}
]
}
