deleteTransparentProxyRules returned before touching the system proxy
whenever no snapshot had been persisted. GetCleanCommands already
handles both cases -- it restores the saved original when a snapshot
exists and falls back to disabling ProxyEnable when none does -- so the
guard only suppressed the fallback that makes the two modes exclusive.
The leftover registry value pointed at 52345, which only the
system_proxy mode ever listens on. Switching back to tun therefore left
proxy-using applications connected to a dead port: their sockets stayed
in SYN_SENT until the process was restarted.
The regression test drives deleteTransparentProxyRules with no snapshot
and asserts the proxy is disabled. Against the previous code it fails
with "the system proxy was never touched"; it passes with this change.
Since v2.4 the dokodemo transparent inbound binds 127.0.0.1 only, so
traffic intercepted by the PREROUTING transparent rules and REDIRECTed
to the interface address (e.g. docker bridge containers) can never
reach it: all bridge-container TCP breaks while transparent proxy is
enabled, a regression from 2.2.x where the inbound listened on 0.0.0.0.
Let the inbound follow the existing 'Allow connections from LAN'
(PortSharing) setting, which the socks/http inbounds
(template_inbound.go) and dns-in (template_outbound.go) already follow.
Default behavior is unchanged (loopback-only with PortSharing off);
with PortSharing on, redirected/forwarded traffic works again.
getsockopt(IP_UNICAST_IF) hands the interface index back in host order while
setsockopt wants it in network byte order, so the second swap in
boundProbeInterface compared 0x01000000 against 1 and the IPv4 cases of
TestBoundDirectDialerSocketOptions failed on Windows.
Revision of the dashboard probe: the UDP fallback used an unmarked, unbound
socket, so its datagram entered the transparent interception the probe is
meant to stay out of and the round trip measured the local stack. Take the
dialer PingWithDialer was given, as the TCP dial already does.
Every core the service starts has outbound traffic counters on, and with them on
xray wraps the underlay connection of a native QUIC outbound in a
*stat.CounterConnection. That wrapper embeds net.Conn alone, so ReadFrom and
WriteTo are hidden and hint/proxy/juicity and hint/proxy/tuic failed their
net.PacketConn assertion before a single QUIC packet left: the node imported, and
then every connection through it died on the spot. Unwrap the stats connection
before the assertion.
A QUIC server listens on UDP only, so the TCP dial the ping made to its port said
nothing and every juicity, tuic and hysteria2 node read TIMEOUT. Keep the TCP
attempt, and when it fails ask the same port over UDP with a QUIC long header
carrying a reserved greased version: a QUIC server answers that with a Version
Negotiation packet (RFC 9000 section 6), and the round trip of that answer is the
latency. A node that answers neither probe is still TIMEOUT; the troubleshooting
pages in the six locales describe that.
Move default: proxy back to the first line so RoutingA.vue treats russia as a replacement, not a snippet. Fix presets.spec.ts to match geosite:category-ru. Remove copyright header per review.
Added rules for youtube, telegram, google - etc - services taht might still operate on .ru and on ru-geoip / geosites.
Signed-off-by: Mishalski <100153948+wywywywycloud@users.noreply.github.com>
xray-core's splithttp range fields (xPaddingBytes, the xmux limits, the
server-checker intervals) parse a plain integer or an "a-b" string, and
reject the object form XHTTPRangeConfig used to serialize to. Any node
with an xhttp range set produced a config the core refused to load with
"Invalid integer range, expected either string of form 1-2 or plain
integer".
XHTTPRangeConfig now carries a MarshalJSON that emits the shorthand (a
plain integer when From equals To, an "a-b" string otherwise) and an
UnmarshalJSON that accepts both forms the core accepts, so generated
configs round-trip. parseRangeString mirrors the core's ParseRangeString
down to its negative endpoints such as "-114-514". Stored settings are
unaffected: the GUI keeps the endpoints as separate query parameters and
nothing parses the generated config back into these structs.
The iptables path wrote each whitelisted CIDR with its own iptables
process. With the mainland China group (about 15,000 CIDRs) a core start
spent minutes on this, and every packet of a direct connection walked
the list linearly.
Load each family into one hash:net set with a single `ipset restore` and
match it with one rule at the old position. Without ipset, write the
rules with one `iptables-restore --noflush` per family; without that,
keep the per-rule commands. Cleanup destroys the sets.
A Shadowsocks link with a stream cipher (rc4-md5, aes-128-cfb, aes-256-cfb,
chacha20-ietf) or with none/plain imported without complaint and failed at
core start with "unknown cipher method", so the user saw a broken core rather
than a refused node. xray-core dropped the stream ciphers in 2021 and never
took none or plain in the shadowsocks outbound; these are also the ciphers
ShadowsocksR providers hand out.
ParseSSURL now refuses them with LINK_UNSUPPORTED_CIPHER, which NewFromLink
passes through instead of calling the link malformed; subscriptions skip such
nodes with a warning as they skip other unparseable ones, and the Clash
importer goes through the same parser. The node form drops none and plain and
offers xchacha20-ietf-poly1305, which the core does accept. The six locales
carry the message, and the quick-start pages say which ciphers work.
The repository had six markdown issue templates, no pull request template and
no guide, so a report rarely said which version it was and a pull request
rarely said what its author had run.
The issue templates become four GitHub forms, English and Chinese kept apart,
asking for the version and why it is not the latest, the system and install
method, the transparent proxy mode, the steps, the logs and the person who
answers for the report. Usage questions go to Discussions through config.yml,
and blank issues are off. The pull request template, also in two languages,
asks for the change in the author's own words, what was executed and observed,
and a checklist of what the review expects; two of its boxes are true only of
someone who checked the list without reading it, or of an agent submitting
without human review, and checking either one closes the pull request.
CONTRIBUTING.md says where the code lives, what to run before opening a pull
request, that all six locales change together and that no AI attribution goes
into the history. AGENTS.md tells an assistant the same in its own terms, with
the traps that cost a review round: the web files the service embeds, the
locale and documentation directories that are named differently, the escaped
@ in a locale string, the Material colour and type tokens, and what in core/
belongs to v2rayA rather than to xray-core.
The page was 1400 px wide on the dashboard, proxies and subscriptions and
1040 px centred elsewhere, so the title and the header's buttons jumped
sideways on every change of view. The page is one width now and only the
body of a reading view is capped at 1040 px, left-aligned under the title.
The app bar's and the page header's group button go: the dashboard's group
card carries the picker with the member editing beside it, the header copy
had no such actions (from the chat).