Introduction

A brief guide to setting up a stealthy, NAT-transversing SSH tunnel using VLESS + REALITY on Debian. This configuration allows you to securely access a private machine (Client) through a public VPS (Server) while masking traffic as a standard TLS handshake to a legitimate website.

1. Pre-requisites

Have xray-core set up and running with a basic VLESS + REALITY configuration Check the previous article. This guide focuses on the additional steps to enable SSH tunneling through the established VLESS + REALITY connection.

Introduction

Bilibili provides Danmaku in an XML format that mpv cannot natively render. Furthermore, Bilibili’s AI subtitles often use non-standard language tags (like ai-zh), which can lead to “null” tracks or rendering errors in older mpv kernels (like the one used in IINA).

Thankfully, yt-dlp allows us to extract and download these Danmaku and AI subtitles; danmaku2ass(deveoped by @m13253) provides a brilliant solution to convert XML files to ASS subtitles.

Introduction

A brief guide to set up a VLESS with Reality server on a Debian-based system using binary releases.

VLESS is a stateless proxy protocol designed for high performance and low overhead. REALITY is a security layer that eliminates TLS fingerprints by “borrowing” the identity of other websites. Together, they provide superior stealth against Deep Packet Inspection (DPI).

• Protocol (VLESS): Handles user authentication (UUID) and data routing. It does not encrypt data on its own.

Description

A brief guide to set up a Shadowsocks server on a Debian-based system using binary releases and systemd.

Steps

1. Pre-requisites

Download and extract the Shadowsocks-Rust binary, and move it to /usr/local/bin for system-wide access:

wget [BINARY_RELEASE_URL]

tar -xvf shadowsocks-rust-<VERSION>-x86_64-unknown-linux-gnu.tar.xz

sudo cp ssserver /usr/local/bin/

2. Server Configuration

Create a config file for the Shadowsocks server under directory /etc/ with the following content (modify as needed):

Issue Description

After use in Xcode, the iOS simulator on macOS occasionally leaves behind mounted disk images that become unresponsive and cannot be unmounted through standard methods. This can lead to cluttered disk space and potential conflicts with future simulator sessions.

• Screenshots of the issue:

In the example above, it was observed that certain simulator disk images, such as disk5s1 and disk7s1, remained mounted but unresponsive. When attempting to unmount these volumes using Disk Utility, it always prompted saying the volume was in use, even after quitting Xcode and all related processes (the CoreSimulator related processes always reappeared after being killed).