Clash Installation
and Setup Guide

Before you start

Check your OS, architecture, and configuration source

Before installing, note your operating system and processor architecture. On macOS, check About This Mac for the chip. On Windows, go to Settings → System → About and check System type. On Linux, run uname -m. Architecture determines whether an app can run; the file format determines how to install it. Neither tells you the other. Check the architecture listed on the download card and the project's minimum OS requirements—not just the OS in the filename.

A client is not a proxy service. It manages configurations, connects to proxies, and routes traffic; you still need a valid subscription URL or a local configuration with a working outbound. Make sure the subscription comes from a trusted source, is still active, and supports your client or core. Subscription URLs often contain account identifiers, so don't post them in public comments, screenshots, or bug reports.

Before switching clients, save your current configuration and note the proxy groups, mixed port, and traffic-routing method in use. Remote subscription updates may overwrite changes. For settings you need to keep, use the client's override, extension, or merge feature when available. Otherwise, test a local copy—but remember it won't inherit future subscription updates automatically.

Understand configurations, outbounds, and traffic routing

A complete connection has three separate steps: load a configuration, decide which outbound handles each request, and route app traffic into the client. A successful import only means the content was saved; it doesn't mean the configuration is active. Seeing proxy groups doesn't mean the system proxy is on. Check each step in order when setting things up, rather than repeatedly toggling network controls before the configuration is active.

Rule mode matches requests in rule order; it doesn't send every request through a proxy. Global mode usually sends requests that have already entered the client to the selected global outbound, but it won't automatically capture apps that bypass the client. Direct mode doesn't mean the client is off—traffic may still pass through its local listener and DNS handling. For details, see How virtual network adapters and system proxies work.

Use one traffic entry point to start

On desktop, start with system proxy only and test in a browser. Use TUN only if an app doesn't respect the system proxy. Mobile clients usually route traffic through the system-approved VPN interface, so you don't need to follow desktop manual-proxy steps. For your first test, disconnect other VPNs, legacy proxy clients, and traffic-routing tools. Leave the regular firewall on and observe the result before changing other settings.

Set up a test you can recover from

Choose a site that normally connects directly to check your base network, and another that should use a proxy under your current rules. On the connections page, check the domain, matched rule, proxy group, and final outbound. A page loading doesn't prove the configuration is correct: caching, existing connections, and direct rules can all affect the result. Make a new request during testing, and restart the app if needed.

Before quitting the client, turn off the system proxy or disconnect the VPN and confirm your network is back. If the system still points to a local proxy port after the client stops listening, apps may lose connectivity. Knowing how to restore your network is more useful than repeatedly reinstalling. When troubleshooting, change one setting at a time and note what you changed so you can identify whether the issue came from the configuration, permissions, or traffic entry point.

Install and configure Clash on macOS

Choose the right build and install it

Open the macOS client downloads and consider Clash Plus first. You can also choose Clash Verge Rev or FlClash based on configuration compatibility. Select the build for your chip: Apple Silicon or Intel. ClashX Meta is an archived, discontinued option for existing setups—not a guarantee of compatibility with newer systems.

Open the disk image and drag the app to the Applications folder, then launch it from there. Don't keep running it from the disk image; updates, helper services, and permission registration may not work reliably. For other file formats, follow the download page and installer instructions. On first launch, verify the app's name and source. Don't disable system security features just to avoid a prompt.

If the app won't open or macOS shows a security warning, first check whether the build matches your architecture, meets the OS requirements, or is being blocked on first launch. For an app from a verified source, check System Settings → Privacy & Security for an option to open it anyway; prompts vary by macOS version. If macOS explicitly says the app is damaged, don't blindly run commands to remove security attributes. Download it again from the verified source first.

Import a subscription and confirm the active configuration

On the configuration page, choose the option to import from a URL, paste the complete subscription URL, and save. Wait for the download to finish. Some clients put this option under Add or New Configuration. After importing, select the configuration and check its status and logs to confirm the core loaded it. If an entry appears but the proxy page is empty, check whether the configuration is active and whether it contains any valid proxy groups.

Import local YAML files from the file picker. Relative references, rule sets, and external resources in the file may still require network access. Keep a copy before editing, especially for generated subscription files—your changes may be lost when you update them. To add a direct rule for a work domain, use the client's persistent extension feature, then check that the rule still applies after a subscription update.

Start with system proxy; add TUN only if needed

On the proxy page, select Rule mode and choose a working outbound for any groups that require manual selection. Then enable the system proxy. The client may request permission the first time it changes network settings; approve only when the request clearly matches the action you're taking. In System Settings → Network, select your current network service and check that its proxy points to the local machine and uses the same port as the client's mixed port. The exact path varies slightly by macOS version.

Browsers usually use the system proxy, but command-line tools may not. To test a specific app's behavior, make one request explicitly through the local port. The example below applies only when the mixed port is set to 7890; if yours differs, use the value shown in the client. This command checks whether an explicit proxy connection can be established using a standard test URL. It does not prove that all rules are correct.

curl --proxy http://127.0.0.1:7890 --head https://example.com

Try TUN only when you need to route traffic from games, command-line tools, or other apps that ignore the system proxy. The client may require a helper service or network extension permission; follow its instructions, then check the logs again. You don't need to enable LAN access for ordinary desktop use. Configure TUN DNS, routes, and interface detection according to your client's documentation—don't copy virtual adapter settings from another platform.

Recover from sleep, network changes, and leftover settings

If proxy requests fail after switching from Wi-Fi to Ethernet or waking from sleep, reconnect first and check which network interface is active. System proxy settings are stored per network service, so the old interface's settings may not match the new one. If TUN is enabled, check that its routes were recreated after the network change. Compare results by turning TUN off and back on; don't reset the entire network at the same time.

If you can't connect after quitting, check whether Web Proxy and Secure Web Proxy in the current network service still point to the local machine. Clear any leftover proxy settings before considering an uninstall. If you installed a helper service, remove it using the client's instructions rather than deleting files from system directories at random. See the client interface guide to learn what the connections and logs pages show and narrow down where the error occurs.

Install and configure Clash on Windows

Choose an installer, check permissions, and launch the app

Open the Windows client downloads and consider Clash Plus first. Other options include Clash Verge Rev, FlClash, and Clash Nyanpasu. Clash for Windows is a discontinued, archived client. Check the system requirements and download card before choosing a build. An ARM64 system doesn't guarantee that any installer will run natively. Also, don't use an installer and a portable archive as if they work the same way.

Run the installer and follow the prompts to choose an installation location. For a portable build, fully extract it to a permanent folder your account can write to, then launch the main program. Don't run it from a compressed-file preview window. Configuration, logs, and update files may be stored in your user data directory, not alongside the app. When moving to a new PC, use the client's export or backup instructions instead of copying only a desktop shortcut.

You don't normally need to run the main app as an administrator for system proxy use. The client may request elevated permissions to install a service, create a virtual adapter, or change specific network settings. If you see a security prompt, verify the publisher, source, and file path first. Organization-managed devices may also have policy restrictions. Running as administrator won't fix an invalid subscription or incorrect outbound, so don't treat it as a universal fix.

Import a configuration and check the system proxy

Import a subscription from the configuration page. Once the update succeeds, select the entry so the core reloads it. On the proxy page, check the groups, choose a known working outbound, and use Rule mode. After enabling the system proxy, go to Settings → Network & Internet → Proxy and confirm that manual proxy settings are active. The client usually sets a local address and listening port, but verify them in Windows Settings.

If a browser works but a desktop app doesn't, check whether that app has its own proxy settings. Some apps follow system settings, some use their own proxy options, and others use different Windows networking components. System proxy doesn't force every process through the client. Don't keep switching to Global mode to fix one app: it changes outbound selection, not how traffic enters the client.

Use curl.exe in PowerShell to test the proxy explicitly and avoid differences in how curl behaves across environments. First confirm the mixed port matches the example, then run the command. If the explicit proxy request works but the target app has no connection record, check how traffic enters the client before changing DNS. Use the connections page to interpret the test alongside its matched rule and outbound.

curl.exe --proxy http://127.0.0.1:7890 --head https://example.com

TUN service, firewall, and UWP loopback

To route traffic from more apps, install the service and enable TUN as instructed by the client. Check the logs for permission, virtual adapter, or routing errors, then test the target app. Review firewall prompts in the context of your network profile and allow only what's needed. Don't enable LAN sharing if you only need local access. The firewall controls inbound access; TUN and proxy rules handle other parts of traffic routing. They aren't interchangeable.

Some Store apps run in an isolated AppContainer and may be unable to reach a local proxy listener. They can fail even when a regular browser works. If your client includes a UWP loopback tool, verify the app's identity and exempt only the apps that need access. See how to configure UWP loopback exemptions with CheckNetIsolation for command-line steps and recovery. Don't grant access to every app at once.

Port conflicts, leftover proxies, and network recovery

If the logs show an address-in-use or listener error, check whether another client instance is running or an old process is still active. The current core must successfully listen on the mixed port, and Windows proxy settings must use that same port. You can change the listening port and update manual settings to match, but don't change only the system proxy port while leaving the client unchanged—or requests will go to a port with no listener.

When you're done, turn off the system proxy and TUN before quitting. If your network stops working after an unexpected shutdown, clear leftover settings on the system proxy page. If only command-line tools fail, check the proxy environment variables in the current terminal. VPNs, virtual machine networks, and corporate security software may all affect routing. Troubleshoot by disabling controllable traffic-routing tools one at a time and noting the results; avoid resetting the entire network as a first step.

Install and configure Clash on Android

Choose a build and grant installation permission

Open the Android client downloads and consider Clash Plus first. Depending on your needs, you can also choose Clash Meta for Android, FlClash, or Surfboard. Clients don't all support the same configuration formats; similar subscription names don't guarantee compatibility. Check which formats your provider supports before choosing a client. That's usually faster than repeatedly trying to convert a subscription that won't import.

Before installing, check your Android version and processor architecture. Most newer devices use ARM64, but appearance and release date aren't reliable indicators. Check device settings or a trusted system information app. A universal build helps with architecture selection but won't bypass an Android version requirement. If the installer reports that the app is incompatible, check the download page requirements rather than trying similarly named files at random.

When you open an installer in a browser or file manager, Android may ask you to allow app installs from that source. Grant temporary permission only to a trusted source and restore the previous setting after installation. If the new package has a different signing key from the existing app, Android may refuse to install over it. Save your configuration and subscription first, then decide whether to uninstall the old app. Don't clear its data without a backup.

Import a subscription and approve the VPN connection

Open configuration management, add a remote subscription or import a local file, and wait for the content to download. Then select it as the active configuration. If you open a link from another app, make sure the selected client receives it. Check that links from the clipboard or a QR code are complete. If an import fails, first confirm the URL returns configuration data—not a login page, web instructions, or an error message.

When you start a connection, Android displays a VPN connection request. Approve it so the client can receive app traffic through Android's VPN interface. This permission doesn't mean a remote outbound has connected successfully; choose a working outbound in the proxy group and check the logs. A VPN icon only shows that the interface is active—it doesn't confirm that the subscription, rules, or DNS are correct.

On Android, traffic-routing options may appear under Network, Routing, or VPN settings rather than as a desktop-style “System Proxy” switch. You usually don't need to enter a local HTTP proxy in Wi-Fi settings. If you've configured a Wi-Fi proxy manually, note its settings and remove them to avoid an extra forwarding layer. A manual proxy for one Wi-Fi network won't carry over to mobile data.

Per-app routing, background activity, and battery limits

To let some apps connect directly, distinguish the per-app list from domain rules. Per-app settings determine which apps enter or bypass the VPN interface; rules determine which outbound handles requests that have entered the core. Allowlist and blocklist behavior varies by client. Before saving, check whether the option means “proxy selected apps only” or “bypass selected apps,” then verify the result on the connections page.

Some apps keep existing connections after you change the configuration. Close and reopen the target app, then check for a new connection record to see whether per-app routing took effect. Work profiles, cloned apps, and multiple user spaces may limit which apps the client can see. Don't assume a VPN in one space automatically covers the others.

Disconnects after locking the screen or updates stopping after a while are often caused by battery management or background restrictions. Check whether the client is allowed to run in the background and whether it needs a persistent foreground-service notification, then adjust the battery settings using your device's own controls. Menu paths vary by manufacturer, so don't follow instructions for another phone blindly. Change permissions only for apps that need them, then test by locking and unlocking the device.

Diagnose mobile network changes and DNS issues

After switching between Wi-Fi and mobile data, existing connections may stop working and need to be re-established. Send a new request and check whether the core still receives traffic. If there are no records, check whether another app has taken over the VPN. Android usually allows only one active VPN per user profile, and ad blockers, work VPNs, or other proxy tools may occupy that slot.

If only domain names fail, consider how Android Private DNS, client DNS, and routing mode interact. Note your current settings, compare using the system's automatic DNS mode, and only then adjust the client's DNS path. Don't disable every network protection feature at once. Clients such as Surfboard use configuration syntax that differs from mihomo YAML, so don't paste YAML snippets into an incompatible configuration editor.

Install and configure Clash on iOS

Install Clash Plus from the App Store

For iPhone and iPad, see the iOS client downloads. Install Clash Plus from its App Store page; the official website is clashplus.io. Check the system requirements listed in the store before installing. For features, menu names, and permissions, follow the current app documentation. Don't apply desktop helper-service installation steps to a mobile device.

After launching the app for the first time, make sure you can open configuration management and the connection screen before preparing a subscription. Installing the app and adding a system VPN configuration are separate steps; seeing the app on your home screen doesn't mean iOS has allowed it to route traffic. If your device is managed by a school or organization, its policies may restrict VPN configurations. Follow the administrator's process rather than repeatedly reinstalling the app.

Before migrating from an old client, note your subscription source, selected proxy group, and custom rules. Apps may use different databases and backup formats. Prefer importing the original subscription or a compatible configuration instead of copying app-private files. Whether a subscription works depends on the client's supported formats and protocols—not on whether the link opens in a browser.

Import a configuration and grant VPN permission

Use the app's Add Configuration, Subscription, or Import File option to enter the complete URL and retrieve its contents. After importing, select the configuration, confirm the proxy groups are visible, and try connecting. When importing through a share menu or clipboard, check that the content wasn't truncated, especially for URLs with query parameters. Subscription details are private; hide identifying information in screenshots shared for troubleshooting.

The first time you connect, iOS may ask permission to add a VPN configuration and request your device passcode or system authentication. Approve it, then return to the app to connect. If you previously denied permission, trigger the request again from the app instead of manually creating an unrelated VPN type. Use the VPN list in Settings to check the active configuration; subscription updates and proxy group selection still happen in the app.

Mobile clients use Apple's network extension to route traffic; you usually don't need to set a Wi-Fi HTTP proxy. A Wi-Fi proxy applies only to that network and doesn't cover cellular data. Configuring one alongside the client's VPN can make troubleshooting harder. Even if the app offers an option similar to TUN, follow its iOS instructions. Don't copy desktop virtual adapter names, service commands, or route settings.

Rule mode, connection checks, and DNS

Start in Rule mode and make sure any proxy groups that require manual selection have a working outbound. Open a site that should use a proxy under your rules, then check the app's connection records or logs. A rule matching Direct doesn't mean the VPN is off—it may be the expected result. If the page loads but traffic uses the wrong outbound, check rule order rather than relying on the connection icon.

Global mode can help determine whether rules are causing a problem, but it isn't a long-term troubleshooting solution. If switching to Global mode fixes the issue, compare the original rules, rule sets, and fallback policy. If it still fails, check the outbound, network, and DNS. Restore the original mode after testing so local services and work apps that should connect directly keep their expected route.

Some browsers, privacy features, and custom DNS settings can change the request path. Note your existing device settings, then compare them with the client logs one at a time. If one site won't load, don't change system DNS, app DNS, and every proxy group at once; even if that works, you won't know why. If you see a certificate warning, don't bypass an ordinary connection issue by trusting an unknown certificate.

Background activity, on-demand connections, and network changes

The VPN network extension and the main app have separate lifecycles. Sending the app to the background doesn't necessarily stop the connection, and force-quitting it isn't a substitute for disconnecting explicitly. When you're done, confirm the connection is off using the app or iOS VPN settings. If the app offers on-demand connections, understand the triggers before enabling them and check whether rules reconnect after a disconnect, so you don't mistake automatic reconnects for a broken switch.

After switching between Wi-Fi, cellular data, and a hotspot, existing connections may need to be re-established. First confirm the current network can connect directly, then reconnect the VPN and make a new request. If the issue occurs only on one Wi-Fi network, check its sign-in portal, DNS, or outbound restrictions. Sign in to the network before testing the proxy so a captive portal isn't mistaken for a client issue.

Whether subscription updates can run in the background or require the app to stay open depends on the app and iOS scheduling. After an important update, open the app and confirm the configuration loaded; don't assume a scheduled update has completed. If an outbound works on another device but fails here, compare protocol support, configuration format, and the current network before deleting system network settings.

Install and configure Clash on Linux

Choose a desktop client or core

Open the Linux client downloads and choose Clash Verge Rev or FlClash for a desktop environment. For servers, routers, and users who manage services themselves, see the Mihomo core downloads. A GUI client manages configurations and displays status; the standalone core only runs a configuration. Installation and permissions differ, so beginners should avoid deploying both at once with the same listening ports.

Run uname -m to check your architecture, then confirm which package format your distribution uses. Commonly, x86_64 corresponds to AMD64 and aarch64 usually corresponds to ARM64, but check the specific build requirements. Don't use another distribution's install commands on a system without its package manager, and don't assume every Linux package works on a headless server.

Installing through your distribution's package manager preserves dependency resolution and uninstall records. If the app reports a missing desktop component, runtime library, or tray support, read the specific error and check your session environment. Wayland, X11, and desktop environments have different tray implementations. A window that runs without a tray icon doesn't necessarily mean the proxy core failed to start; check the UI and core logs separately.

Import a configuration and route desktop traffic

Import and select a subscription on the client's configuration page. Confirm the core loaded it before enabling the system proxy. Linux has no single proxy setting that works for every desktop and app. GNOME, KDE, and command-line programs may use desktop settings, environment variables, or their own proxy configuration. Even when the client says the system proxy is on, test the app you want to use.

If your browser has its own proxy settings, check whether it follows system settings or uses a manually specified address. For terminal apps, test with an explicit proxy command first to confirm the local listener works, then decide whether to set environment variables. Don't add the same variables to every startup script: desktop sessions, interactive shells, and system services inherit different environments. A variable in the wrong place can leave some apps using an outdated proxy.

This example assumes the mixed port is set to 7890 and affects only the current shell and child processes started from it. NO_PROXY tells compatible apps to bypass the proxy for local addresses; it doesn't define the core's full direct-routing rules. Support for variable capitalization and wildcard syntax varies by tool, so check its documentation before using this in production.

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,::1

curl --proxy http://127.0.0.1:7890 --head https://example.com

unset HTTP_PROXY HTTPS_PROXY NO_PROXY

Check a standalone core configuration and TUN permissions

When using the Mihomo core, prepare a complete configuration and a separate data directory, then validate the configuration as a regular user. These commands assume the core is installed as mihomo and the configuration is saved at the specified path; they won't generate a subscription or fill in missing proxy groups. A successful check only confirms the configuration can be parsed. Validate remote rule resources and outbounds after starting the core.

mkdir -p "$HOME/.config/mihomo"
mihomo -t -d "$HOME/.config/mihomo" \
  -f "$HOME/.config/mihomo/config.yaml"

TUN needs access to a virtual network device and permission to change routes, which usually requires network administration capabilities or a controlled privileged service. If your desktop client offers service installation, follow its instructions. When managing a service yourself, define its user, file permissions, and capability scope. Don't make the entire configuration directory writable by everyone or let an unknown script run as root indefinitely.

Containers, virtual machines, and the host are separate network environments. Loopback inside a container points to the container itself; the host's local proxy isn't automatically available there. Before sharing a listener, plan address reachability, listening scope, and firewall rules, then decide whether LAN access is appropriate. Listening on every interface can expose a service intended for local use to other devices.

Service status, logs, and network recovery

If a background service fails to start, check the service manager report and core logs to distinguish an incorrect configuration path, unreadable directory, port conflict, or insufficient permissions. If the GUI client has already started a core and you launch another manually, they may conflict over the listening port. After editing the configuration, reload or restart it according to your deployment method; editing a file doesn't necessarily update a running core.

If LAN, container, or VM networking breaks after enabling TUN, check whether new routes overlap existing private subnets and where DNS requests are ultimately resolved. Disable TUN temporarily to compare while keeping a regular proxy test available. Don't flush all routes or firewall rules; you could lose remote access. Make sure you have a separate recovery path before changing a server.

When disabling the client, also reset desktop proxy settings, shell environment variables, and background services; they don't necessarily stay in sync. If only one terminal still fails, open a new one and check its inherited environment. If all desktop apps fail, check desktop network settings. For core field compatibility, see configuration differences between mihomo and original Clash. Don't assume an unsupported legacy field is a distribution issue.

Configuration FAQ and troubleshooting

Why can't I connect after importing a configuration?

Check four steps in order: configuration loading, traffic entry point, rule matching, and remote connection. Confirm the newly imported entry is active, then check the logs for parsing or resource download errors. Next, verify that system proxy, VPN, or TUN is routing the target app into the core. If the connections page shows nothing, fix the entry point first. If there is a record, check the matched rule and final outbound instead of toggling controls at the wrong layer.

If every outbound fails, check your base network and subscription status first. If only one fails, check that outbound and its protocol support. Subscription update failures and proxy connection failures can follow different paths: updating requires fetching remote content, while the existing configuration may still connect. Don't delete the only working configuration just because an update reports an error. Save a copy and the error details first.

Use logs to locate the problem, but avoid leaving verbose logging enabled. When reporting an issue, include only the necessary context and hide subscription URLs, outbound account details, personal domains, and device information. For the same symptom, test time, network, mode, and whether TUN was enabled are more useful than simply saying “can't connect.” Make sure the logs cover the new request you tested, not an old error from a previous session.

How do rules, the mixed port, and YAML fit together?

A mixed port usually lets one local listener accept both HTTP proxy and SOCKS requests; it isn't the remote server's port. Rules are matched from top to bottom, with more specific exceptions usually placed first and a final fallback rule at the end. The minimal direct-connection configuration below only tests the local listener and contains no remote proxy. It can run on its own, but won't forward requests through a remote outbound and shouldn't replace an existing subscription.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
  - DOMAIN-SUFFIX,localhost,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

For remote proxying, define the actual outbound or proxy group in a complete configuration, then reference its exact name in your rules. The private-address rules in the example cover only the listed subnets; they aren't a universal solution for every LAN. YAML indentation uses spaces, and list dashes and field levels matter—don't use tabs. Validate the configuration after editing, then reload it. If validation fails, restore your last working copy.

How do system proxy, TUN, DNS, and speed tests differ?

System proxy works for apps that follow system settings. TUN routes a wider range of traffic but adds routing, permission, and DNS considerations. You don't need both enabled on every platform. Fake-IP is a DNS mapping and connection-restoration mechanism, not a proxy mode or speed boost. For LAN domains, hard-coded IPs, or app compatibility issues, check DNS and connection records and adjust accordingly instead of disabling features based on their names.

A browser's encrypted DNS, the OS resolver, and client DNS may all handle different parts of a request. Changing system DNS won't necessarily change the browser's resolution path. Domain-based rules also depend on the client being able to identify the domain. First check whether the request uses a domain or IP, then review the resolver and sniffing behavior. Don't layer DNS hijacking, sniffing, and multiple fallback resolvers without evidence that you need them.

A node latency test measures a specific request at a specific time; it doesn't represent download bandwidth or performance across all sites. A timeout can also be caused by the test URL, certificates, DNS, or connection reuse. Choose an outbound based on the sites you use, reliability, and real workloads. See node latency versus real-world speed for details. After switching outbounds, start a new connection—existing connections may not move immediately.

Subscription updates, LAN sharing, and recovery checks

Automatic updates fetch subscription content again and may overwrite rules written directly into a generated file. Put persistent changes in a client-supported extension and confirm the merged rule order. Subscription converters can access configuration content, so understand how they handle it before use. If a compatible subscription works as-is, there's no need to add a conversion step. Check the source, validity, and terms of use for free nodes; the client can't guarantee them.

To start again with the shortest setup, return to the quick start guide. To switch clients, choose a platform on the downloads page. Keep a verified configuration and a record of its settings; that makes it easier to maintain a network setup you can recover than trying several sets of options at once.