V2Ray Configuration Reference

JSON Structure Overview: How the Config File Is Organized

V2Ray's core config file uses JSON, a text format that is clear and easy for machines to parse. Both v2rayN and v2rayNG rely on the V2Ray core to parse this config. Understanding the JSON structure is the foundation for troubleshooting and customizing behavior. The config file is usually named config.json and stored in the client's config directory.

The top-level fields of a V2Ray config file are six: log for logging, inbounds for inbound connections, outbounds for outbound connections, routing for routing, dns for DNS resolution, and policy for policy. Among them, inbounds and outbounds are required; the rest are optional. There is also an api field for remote control, which is less commonly used.

Top-Level Fields Overview

The table below summarizes all top-level fields in a V2Ray config file and what they do. Understanding how these fields relate is the first step to reading a config.

Config File Loading Mechanism

When the core starts, it reads config.json and parses each field in order. If a field is missing, the core uses default values. For example, if the dns field is missing, the core uses the system's default DNS resolution; if the routing field is missing, all traffic goes to the first outbound. In v2rayN, every time you switch nodes or change settings, the program regenerates a new config.json in the background and restarts the core.

Therefore, if you manually edit the config file and then change settings in the UI, your manual edits will be overwritten. v2rayN provides an 'Open Config Directory' feature that lets you edit the config file directly, but you need to stop the core first. You can find the config directory entry in v2rayN's Settings → Parameter Settings.

JSON Syntax Notes

The JSON standard doesn't support comments, but the V2Ray core ignores // and /* */ comments when parsing. This allows config files to contain comments for readability. However, in v2rayN's auto-generated configs, comments are removed. If you edit the config manually, it's recommended to keep comments but not rely on them as part of the functional logic.

A common mistake is missing commas or mismatched quotes. JSON strictly requires commas to separate elements inside objects and arrays, and no trailing comma after the last element. When editing config manually, it's recommended to use an editor with JSON syntax highlighting (like VS Code) to quickly spot syntax issues.

Besides syntax, field value types are also error-prone. For example, port must be a number, not a string, and udp must be a boolean, not a string. If the type is wrong, the core can still parse the JSON but will throw a runtime error. Therefore, when editing config manually, besides checking syntax, you also need to verify that each field's type matches what the core expects.

Additionally, the V2Ray core is lenient about unknown fields when parsing configs and will ignore fields it doesn't recognize. This means even if you add an extra field, the core won't error, but that field won't take effect. If you find a setting isn't working, first check that the field name is spelled correctly, then confirm whether the field is supported by your current core version.

Inbounds Configuration: How to Open Traffic Entrances

Inbounds (inbounds) are the entry points where the V2Ray core provides services. v2rayN creates two inbounds by default: a SOCKS inbound and an HTTP inbound, to support different types of client connections. In Parameter Settings, you can change the listening ports of these two inbounds. The core fields of an inbound config include: port (listening port), listen (listening address), protocol (inbound protocol), and settings (protocol settings).

Common inbound protocols include socks, http, vmess, trojan, and others. For local proxy scenarios, socks and http are the most commonly used. v2rayN uses the SOCKS inbound as the main entry by default, with the HTTP inbound as a compatibility entry, both listening on the local loopback address.

{
  "inbounds": [
    {
      "port": 10808,
      "listen": "127.0.0.1",
      "protocol": "socks",
      "settings": {
        "udp": true,
        "auth": "noauth"
      }
    },
    {
      "port": 10809,
      "listen": "127.0.0.1",
      "protocol": "http",
      "settings": {
        "timeout": 300
      }
    }
  ]
}

SOCKS Inbound Explained

In a SOCKS inbound's settings, the udp field controls whether UDP forwarding is supported. When UDP is enabled, the core forwards UDP traffic over SOCKS, which is necessary for some UDP-based applications (like gaming and video calls). The auth field controls the authentication method; noauth means no authentication is required, suitable for local proxy. If you need to prevent other devices on the LAN from using the proxy without authorization, you can set it to password and configure a username and password.

HTTP Inbound Explained

In an HTTP inbound's settings, you can configure the timeout field, which represents the connection timeout in seconds. The HTTP inbound is typically used to support applications that don't support the SOCKS protocol. In v2rayN, both inbounds listen on 127.0.0.1 by default, meaning only local connections are allowed.

Multiple Inbounds & LAN Sharing

In the config file, inbounds is an array that supports multiple inbounds at the same time. Each inbound has its own port and protocol. v2rayN's Parameter Settings has an 'Allow connections from LAN' option. When enabled, the inbound's listen address changes from 127.0.0.1 to 0.0.0.0, allowing other devices on the LAN to connect. This feature is very useful when you need to share the proxy with devices like phones and TVs.

Port Conflict Troubleshooting

If the configured port is already occupied by another program, the core will fail to start. v2rayN will show a 'Port already in use' error. In this case, you need to change the inbound port or close the program using the port. On Windows, you can use the netstat -ano | findstr 10808 command to check port usage, then end the corresponding process in Task Manager. When changing the port, you also need to update the proxy settings of other software on your system (like browser extensions).

Besides port conflicts, another situation is when the port is reserved by the system. Windows' 'Excluded port ranges' feature reserves a range of ports. If your configured port falls within a reserved range, the core also cannot listen. In this case, you can try a different port, or run netsh int ipv4 show excludedportrange protocol=tcp in an administrator command prompt to see the reserved port ranges.

After changing the inbound port in v2rayN, it's recommended to also check whether the system proxy settings have been updated accordingly. If the system proxy still points to the old port, browsers won't be able to access the internet properly. v2rayN usually updates the system proxy when switching nodes or changing settings, but after manually editing the config file, you need to verify this yourself.

Outbounds Configuration: How Traffic Exits

Outbounds (outbounds) are the channels through which the V2Ray core makes outgoing connections. When switching nodes, v2rayN generates the corresponding outbound config based on the selected node's protocol. The outbound protocol determines how communication with the remote server is carried out. Common outbound protocols include: vmess, vless, trojan, shadowsocks, freedom (direct), and blackhole (drop). Among them, vmess and vless are protocols unique to the V2Ray ecosystem, while trojan and shadowsocks are general-purpose proxy protocols.

An outbound config includes: protocol (protocol type), settings (protocol settings), streamSettings (transport settings), and mux (multiplexing). streamSettings defines the transport method (tcp, ws, grpc, etc.) and security settings (tls, reality). When using WebSocket, you need to specify path and headers; when using TLS, you need to specify serverName and allowInsecure.

VMess Outbound Config

{
  "outbounds": [
    {
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "address": "example.com",
            "port": 443,
            "users": [
              {
                "id": "your-uuid-here",
                "alterId": 0,
                "security": "auto"
              }
            ]
          }
        ]
      }
    }
  ]
}

A vmess outbound's settings contains a vnext array, where each vnext object represents a server. address is the server address, port is the server port, and users is the user list. Each user has an id (UUID), alterId (additional ID), and security (encryption method). In newer core versions, it's recommended to set alterId to 0 for better security.

VLESS Outbound Config

A vless outbound is similar to vmess, but the vless protocol itself doesn't provide encryption and relies on TLS or REALITY transport security. In a vless outbound's settings, each user in the users array contains id, encryption (encryption method, fixed to none in vless), and flow (flow control, such as xtls-rprx-vision). The flow control field is an advanced feature unique to the vless protocol that can optimize TCP transport performance.

streamSettings Transport Settings

streamSettings is one of the most important parts of an outbound config. The transport method (network) determines how data is encapsulated. Common transport methods include tcp, ws (WebSocket), grpc, http/2, and others. When using ws, you need to specify path and headers; when using grpc, you need to specify serviceName. The security setting (security) can be none, tls, or reality. When using TLS, serverName must match the server's certificate domain.

Mux Multiplexing

The mux field controls whether multiplexing is enabled. When enabled, a single TCP connection can carry multiple concurrent requests, reducing the overhead of connection establishment and helping connection stability in weak network environments. The enabled field of mux is off by default. In v2rayN, you can enable it via Parameter Settings → Multiplexing. Multiplexing is suitable for scenarios with many short connections, but not all servers support it, so it's recommended to test before enabling.

The core parameter of multiplexing is concurrency, which represents the maximum number of concurrent requests carried on a single connection. The default value is 8, and you can adjust it as needed. If a server has limits on concurrent connections, too large a concurrency value may cause connections to be rejected by the server. Therefore, after enabling multiplexing, it's recommended to observe for a while and confirm the connection is stable before adjusting the parameter.

Note that the compatibility of multiplexing with certain protocols (like REALITY) needs to be tested. Some servers may experience connection issues after multiplexing is enabled. In that case, you can try disabling multiplexing or lowering the concurrency value.

Routing Rules: How Traffic Is Split

Routing rules (routing) are one of V2Ray's core features; they determine how traffic is split. The routing field contains a rules list and a strategy. Each rule defines matching conditions and the corresponding outbound. Rule matching conditions include: domain (domain matching), ip (IP address matching), port (port matching), network (network type matching), and inboundTag (inbound tag matching).

Rules are matched from top to bottom, and the first matching rule takes effect. If no rule matches, traffic goes to the first outbound (usually the proxy). Therefore, when configuring routing rules, you need to pay attention to the order of rules. v2rayN's default routing rules place 'Bypass LAN' and 'Bypass mainland China' at the front, ensuring these traffic types are directly connected first.

Common Rule Examples

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": [
          "10.0.0.0/8",
          "192.168.0.0/16",
          "172.16.0.0/12"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:geolocation-!cn"
        ],
        "outboundTag": "proxy"
      }
    ]
  }
}

In the example above, the first rule matches private IP ranges and goes direct; the second rule matches mainland China domains and goes direct; the third rule matches non-mainland China domains and goes through the proxy. Here, predefined domain sets like geosite:cn and geosite:geolocation-!cn are used. These are built into the V2Ray core and require no manual maintenance.

Domain Matching Methods

In v2rayN, routing rules can be configured in Settings → Routing Settings. v2rayN provides a 'Domain Strategy' option that controls how domains are matched: as-is means matching directly using the domain; ip-if-non-match means if the domain doesn't match any rule, resolve the domain and match by IP; ip-on-demand means resolve the domain on demand to match IP rules. Among these, ip-on-demand is suitable for scenarios that need IP-based routing, but it increases the number of DNS resolutions.

Routing Strategies

Routing rules typically include three strategies: direct (direct), proxy (proxy), and block (block). Direct means traffic connects to the target address without going through the proxy server; proxy means traffic is forwarded through the proxy server; block means traffic is dropped directly, often used to block ads and malicious websites. In v2rayN, direct and block are built-in outbound tags and require no extra configuration.

Routing Rules & Inbound Tags

When multiple inbounds are configured, you can use the inboundTag field to route traffic from specific inbounds to different outbounds. For example, you can make traffic from the LAN sharing inbound go direct, while traffic from the local SOCKS inbound goes through the proxy. This configuration is very useful when you need fine-grained control over traffic from different sources.

Before using inboundTag, you need to configure the tag field for the inbound. For example, in inbounds, set "tag": "socks-in" for the SOCKS inbound, then write "inboundTag": ["socks-in"] in the routing rules. This way, only traffic from that inbound will match this rule.

In v2rayN, inbound tags are usually generated automatically by the program, so users generally don't need to configure them manually. However, if you need fine-grained control over traffic from different sources, understanding this mechanism is very helpful.

DNS Config: How Domain Resolution Is Handled

DNS config (dns) determines how V2Ray resolves domains. The dns field contains a servers list. Each server can specify address (address), port (port), and domains (domain list). V2Ray supports multiple DNS protocols, including UDP, TCP, DoH (DNS over HTTPS), and DoT (DNS over TLS).

In v2rayN, DNS settings are located in Parameter Settings → DNS. v2rayN generates a set of DNS server configs by default, usually including a public DNS (like 1.1.1.1) and a local DNS (like 223.5.5.5). V2Ray tries DNS servers in list order; if the first server doesn't respond, it uses the next one.

{
  "dns": {
    "servers": [
      {
        "address": "1.1.1.1",
        "port": 53,
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      {
        "address": "223.5.5.5",
        "port": 53,
        "domains": [
          "geosite:cn"
        ]
      },
      {
        "address": "localhost",
        "port": 53
      }
    ]
  }
}

In the example above, 1.1.1.1 handles non-mainland China domains, 223.5.5.5 handles mainland China domains, and the last localhost serves as a fallback. This routing strategy can speed up access within China while ensuring that foreign domain resolution isn't polluted.

FakeDNS Principles & Configuration

FakeDNS is a special DNS mode in V2Ray. When enabled, upon receiving a DNS query, V2Ray immediately returns a fake IP from a reserved range (such as 198.18.0.0/15) instead of waiting for real DNS resolution. When traffic passes through routing rules, V2Ray re-matches routes based on the target domain and restores the real domain at the outbound. FakeDNS can significantly reduce DNS resolution latency and is especially suitable for use with TUN mode.

In v2rayN, FakeDNS mode needs to be enabled in Parameter Settings → DNS. Once enabled, v2rayN automatically adds a fake-dns server to the generated config. Note that FakeDNS may conflict with certain routing rules; for example, IP-based matching rules may not correctly match fake IPs. Therefore, when using FakeDNS, it's recommended to prioritize domain rules and avoid IP rules.

How DNS Works with Routing Rules

DNS config and routing rules work closely together. In routing rules, if you use domain sets like geosite:cn, V2Ray needs to resolve domains before matching. In this case, the domains field in the DNS config helps V2Ray decide which DNS server to use for which domains. A well-designed DNS routing strategy can reduce the impact of DNS pollution and improve access speed.

When using FakeDNS, DNS resolution is deferred to the outbound stage. Domain matching in routing rules still works, but IP matching may fail. Therefore, if you use both FakeDNS and routing rules, it's recommended to put domain rules first and avoid relying on IP rules. This way, you can enjoy FakeDNS's low latency while ensuring accurate routing.

Additionally, the queryStrategy field in the DNS config controls the IP type to query (IPv4, IPv6, or both). In environments where IPv6 is unstable, you can set it to UseIPv4 to avoid connection issues caused by IPv6 resolution failures.

Policy: How Connection Behavior Is Controlled

The policy field controls connection behavior. It contains levels (level settings) and system (system settings). system configures global connection limits, including connectionTimeout (connection timeout), handshakeTimeout (handshake timeout), maxConnections (maximum connections), and more.

In v2rayN, you can adjust these values via Settings → Parameter Settings → Policy. By default, V2Ray uses system defaults. For most scenarios, the defaults are sufficient. However, in high-concurrency or special network environments, you may need to adjust the timeout values.

system Settings Explained

{
  "policy": {
    "system": {
      "connectionTimeout": 300,
      "handshakeTimeout": 60,
      "maxConnections": 0,
      "minPort": 0,
      "maxPort": 0
    },
    "levels": {
      "0": {
        "connIdle": 300,
        "uplinkOnly": 0,
        "downlinkOnly": 0,
        "statsUserUplink": false,
        "statsUserDownlink": false
      }
    }
  }
}

Connection timeout (connectionTimeout) controls the maximum wait time for establishing a TCP connection. If the connection times out, the core returns an error and closes the connection. Handshake timeout (handshakeTimeout) controls the maximum wait time for the TLS handshake. In weak network environments, appropriately increasing the timeout can improve connection stability. maxConnections set to 0 means no limit on the number of connections.

levels Settings

The levels setting allows you to configure different policies based on user levels. Each user can have a level field, and policies can set connection and speed limits per level. connIdle represents the idle connection timeout in seconds; connections with no data interaction for longer than this time will be closed. uplinkOnly and downlinkOnly represent the allowed uplink/downlink duration for a connection; 0 means no limit.

In v2rayN, user levels are usually not directly exposed, but understanding this mechanism helps with advanced configs. For example, if a node frequently has connections dropped by the server, it might be because the server has a connIdle policy and the client isn't sending heartbeat packets in time.

Policy & Connection Stability

A reasonable policy config can improve connection stability. If the network environment is poor, you can increase the connectionTimeout value. If connections are frequently closed early by the server, you can increase the connIdle value. However, note that overly large timeout values consume more system resources, so you need to balance based on your actual network environment.

In v2rayN, policy settings usually don't need manual adjustment; the defaults cover most scenarios. But if you're using it in a weak network environment, or connections are frequently dropped by the server, you can try increasing the timeout values in Parameter Settings → Policy. After adjusting, it's recommended to restart the core to apply the new policy.

Additionally, the statsUserUplink and statsUserDownlink fields in levels control whether to track users' uplink/downlink traffic. When enabled, the core records traffic data for each user, which can be queried via the api field. However, the stats feature incurs some performance overhead, so if you don't need traffic stats, it's recommended to keep it off.

Complete Config Example: A Real, Ready-to-Use Config

Below is a complete config example that includes a SOCKS inbound, an HTTP inbound, a vmess outbound, a freedom direct outbound, plus routing rules and DNS config. This config can be used directly with the V2Ray core, or serve as a reference for v2rayN's generated config.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "port": 10808,
      "listen": "127.0.0.1",
      "protocol": "socks",
      "settings": {
        "udp": true,
        "auth": "noauth"
      },
      "tag": "socks-in"
    },
    {
      "port": 10809,
      "listen": "127.0.0.1",
      "protocol": "http",
      "settings": {
        "timeout": 300
      },
      "tag": "http-in"
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "address": "example.com",
            "port": 443,
            "users": [
              {
                "id": "your-uuid-here",
                "alterId": 0,
                "security": "auto"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "example.com"
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "10.0.0.0/8",
          "192.168.0.0/16",
          "172.16.0.0/12"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:geolocation-!cn"
        ],
        "outboundTag": "proxy"
      }
    ]
  },
  "dns": {
    "servers": [
      {
        "address": "1.1.1.1",
        "port": 53,
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      {
        "address": "223.5.5.5",
        "port": 53,
        "domains": [
          "geosite:cn"
        ]
      },
      {
        "address": "localhost",
        "port": 53
      }
    ]
  }
}

Config Highlights Explained Section by Section

The first part of this config sets the log level to warning, meaning only warnings and errors are output, avoiding frequent log spam. The two inbounds listen on ports 10808 and 10809 respectively, both bound to the local loopback address, ensuring only the local machine can access them.

The outbound section has three tags: proxy uses the vmess protocol to connect to the remote server, with TLS encryption for transport security; direct uses the freedom protocol for direct connections; block uses the blackhole protocol to drop traffic. The routing rules direct private IP ranges and mainland China domains to direct, and non-mainland China domains to the proxy.

In the DNS config, 1.1.1.1 handles non-mainland China domains, 223.5.5.5 handles mainland China domains, and localhost serves as a fallback. This setup effectively reduces the impact of DNS pollution while ensuring fast access within China.

GUI Clients & Config Files: How v2rayN / v2rayNG Manage Configs

Both v2rayN and v2rayNG use the V2Ray core, but they manage config files differently. v2rayN runs on Windows, stores config files in the user directory, and regenerates config.json every time you switch nodes. v2rayNG runs on Android, stores configs in the app's private directory, and supports multiple config files.

v2rayN Config Management

v2rayN's UI operations generate the various fields of the config file. When you add a node in the Servers panel, v2rayN generates the corresponding outbounds config when switching nodes. You can adjust routing rules in Settings → Routing Settings, and v2rayN writes these settings into the routing field. In Parameter Settings, you can modify inbound ports, enable FakeDNS, adjust multiplexing, etc. All these operations are reflected in the generated config file.

v2rayN provides an 'Open Config Directory' feature that lets you edit the config file directly. However, note that if you manually modify the config file and then perform any operation in the UI, v2rayN will regenerate the config file and overwrite your manual changes. Therefore, before manually editing the config, it's recommended to stop the core first, then restart it after editing.

v2rayNG Config Management

v2rayNG stores configs in the Android app's private directory. You can import configs from a file or subscription via Config → Import Config. v2rayNG supports multiple config files, each containing different nodes and settings. When switching config files, v2rayNG reloads the corresponding config.json.

In v2rayNG, you can adjust DNS and routing configs via Settings → DNS and Settings → Routing. v2rayNG also supports FakeDNS mode, which adds a fake-dns server to the generated config when enabled. For advanced users, v2rayNG provides an 'Edit Config File' feature that allows direct modification of the JSON config.

Subscriptions & Config Files

Both clients support subscriptions, where subscription links automatically update the node list. A subscription link is essentially a remote JSON list that v2rayN and v2rayNG periodically fetch and parse. After a subscription update, the client regenerates the config. Note that the subscription link itself doesn't contain routing rules or DNS config; these settings still need to be configured manually in the client.

For v2flyNG users, config management is essentially the same as v2rayNG, except it uses the v2fly core instead of the Xray core. All three clients maintain the same field structure in config files, so the same config.json can theoretically be used interchangeably, but you need to be aware of field compatibility issues that may arise from core version differences.

Subscription links usually contain encrypted information, so don't share them casually. If a subscription link leaks, others may use your nodes and consume your traffic. It's recommended to periodically change your subscription link and enable 'Subscription Update Reminder' in the client to stay informed about node changes. Also, subscription updates overwrite the node list, so if you've manually added nodes, it's recommended to back them up first.

Common Config Errors & Troubleshooting

Config errors are one of the most common issues when using V2Ray. Knowing the common error types and troubleshooting methods can greatly reduce troubleshooting time. Below are several high-frequency errors and their solutions.

Port Already in Use

When the configured inbound port is already occupied by another program, the core fails to start. v2rayN shows a 'Port already in use' error. Solution: change the inbound port, or close the program using the port. On Windows, you can use the netstat -ano | findstr 10808 command to check port usage, then end the corresponding process in Task Manager.

If you change the port, you also need to update the system proxy settings accordingly. On Windows, system proxy settings are located in Settings → Network & Internet → Proxy. On macOS, system proxy settings are located in System Preferences → Network → Advanced → Proxies. Make sure the SOCKS port and HTTP port match your config.

JSON Syntax Errors

If the config file has syntax errors, the core will fail to start. Common syntax errors include: missing commas, mismatched quotes, and unbalanced brackets. In v2rayN, you can find config.json via Config → Open Config Directory and check the syntax with a text editor. It's recommended to use an editor with JSON syntax highlighting to quickly locate errors.

Certificate Config Errors

When using TLS or REALITY, certificate config errors can cause connection failures. Common errors include: serverName not matching the certificate, expired certificates, and improper allowInsecure settings. In v2rayN, you can check certificate settings via Node Config → Transport Security. If using a self-signed certificate, you need to set allowInsecure to true, but this reduces security.

Routing Rule Misconfiguration

Improper routing rule config can cause traffic to go through the wrong channel. For example, incorrectly matching mainland China domains to the proxy will result in slow access. Troubleshooting: check the traffic flow in the logs and review the order of routing rules. In v2rayN, you can view the currently active routing rules via Settings → Routing Settings. If you find the rule order is unreasonable, you can adjust the arrangement.

Another common issue is the conflict between FakeDNS and IP rules. After enabling FakeDNS, V2Ray returns fake IPs, so if routing rules contain IP-based matching, they may not match correctly. The solution is to prioritize domain rules or turn off FakeDNS.

Other Reasons for Core Startup Failure

Besides the above reasons, core startup failure can also be caused by incorrect config file paths, insufficient permissions, missing required runtime libraries, etc. In v2rayN, you can check the core path via Settings → Core Settings. If using the portable version, make sure the relative path between the core file and config file is correct.

If the logs show that the core file cannot be found, it means the v2rayN config directory is missing xray.exe or v2ray.exe. In this case, you need to re-download the client and ensure the core files are complete. Additionally, antivirus software may mistakenly delete core files. If the core keeps 'disappearing', add the v2rayN directory to your antivirus whitelist.

Another situation: the core file exists, but its version doesn't match the client. For example, after v2rayN updates, the old core may not be compatible with the new config format. In this case, click 'Update Core' in Core Settings or re-download the corresponding core version.