<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Proxy on Geek Vinkey</title>
    <link>https://www.mawenqian.com/en/tags/proxy/</link>
    <description>Recent content in Proxy on Geek Vinkey</description>
    <image>
      <title>Geek Vinkey</title>
      <url>https://www.mawenqian.com/images/papermod-cover.png</url>
      <link>https://www.mawenqian.com/images/papermod-cover.png</link>
    </image>
    <generator>Hugo</generator>
    <language>en</language>
    <copyright>MA Wenqian · mawenqian.com</copyright>
    <lastBuildDate>Fri, 25 Sep 2026 09:55:42 +0800</lastBuildDate>
    <atom:link href="https://www.mawenqian.com/en/tags/proxy/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Claude Desktop over SSH: Giving the Remote Claude Its Own Proxy</title>
      <link>https://www.mawenqian.com/en/claude-desktop-ssh-proxy/</link>
      <pubDate>Thu, 24 Sep 2026 11:00:00 +0800</pubDate>
      <guid>https://www.mawenqian.com/en/claude-desktop-ssh-proxy/</guid>
      <description>&lt;p&gt;The Code tab in Claude Desktop can add an SSH connection and run Claude Code on a remote server. The app uploads the program to the server itself and takes care of authentication, so &lt;strong&gt;you don&amp;rsquo;t need to install Claude on the server or sign in there&lt;/strong&gt;.&lt;/p&gt;
&lt;p&gt;The catch: if the server&amp;rsquo;s outbound connection can&amp;rsquo;t reach Anthropic (a server in a region Anthropic doesn&amp;rsquo;t serve, such as Hong Kong, gets refused), or you want to pin it to a specific egress, the remote Claude can&amp;rsquo;t send its requests. The fix is to give Claude on the server its own proxy. It only affects Claude and leaves the rest of the machine&amp;rsquo;s networking alone.&lt;/p&gt;</description>
    </item>
    <item>
      <title>One SSID, Everything Proxied: Routing an OpenWrt Subnet into mihomo</title>
      <link>https://www.mawenqian.com/en/openwrt-wifi-mihomo/</link>
      <pubDate>Thu, 20 Aug 2026 20:00:00 +0800</pubDate>
      <guid>https://www.mawenqian.com/en/openwrt-wifi-mihomo/</guid>
      <description>&lt;p&gt;A separate subnet on OpenWrt, bound to its own SSID, with source-based policy routing that sends the entire subnet to a mihomo TUN gateway sitting on a &lt;em&gt;different&lt;/em&gt; subnet. Clients configure nothing: join the SSID and traffic is proxied, switch back to the main WiFi and it is direct again. There is one well-hidden trap at the end — ImmortalWRT&amp;rsquo;s DNS redirect.&lt;/p&gt;
&lt;p&gt;The gateway itself is built in the previous post: &lt;a href=&#34;https://www.mawenqian.com/en/mihomo-macvlan-gateway/&#34;&gt;Running mihomo as a LAN gateway with Docker macvlan&lt;/a&gt;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Running mihomo as a LAN Gateway with Docker macvlan</title>
      <link>https://www.mawenqian.com/en/mihomo-macvlan-gateway/</link>
      <pubDate>Thu, 20 Aug 2026 19:30:00 +0800</pubDate>
      <guid>https://www.mawenqian.com/en/mihomo-macvlan-gateway/</guid>
      <description>&lt;p&gt;I run mihomo in Docker on an N95 mini PC. macvlan gives the container its own LAN address (&lt;code&gt;10.0.0.6&lt;/code&gt;), so any device that points its default gateway there gets rule-based proxying — without touching the router&amp;rsquo;s own routing table.&lt;/p&gt;
&lt;p&gt;Two things bite you once the container is up: the host and its own macvlan containers cannot reach each other, and you still have to decide how clients switch over to the new gateway. This post covers both.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
