http://192.168.254.2:8000/ would probably work.

It does, but only if I disable extensions that have configured proxy settings.

Could this be summed up as: a FR for a supported way of letting Chrome access URLs served by the Android container?

So the intention is to have e.g. http://android:8000/ bypass proxies and connect to the Android guest's IP?

FWIW: we ran into a similar issue with a "browserbench" CTS test that started up a local web server to serve up browser benchmark pages, then sent an intent for http://127.0.0.1:... which was handled by Chrome.  We never had to commit a fix for this because the CTS test was removed.

Since this works for Chrome Apps (for example, https://chrome.google.com/webstore/detail/web-server-for-chrome/ofhbbkphhbklhfoeikjpcbhemlocgigb) I expect this to work for Android apps as well.

While it's somewhat unexpected I wouldn't have a problem with using something other than localhost to refer to the Android guest but we should be sure that whatever we do doesn't shadow a real IP that could be on the user's network.

This issue blocks using apps such as GNURoot Debian or Termux to set up a local web development environment under ARC++ which is something I've been excited about being able to do ever since the feature was announced.

> we should be sure that whatever we do doesn't shadow a real IP that could be on the user's network

This is being addressed separately.  We have allocated a dedicated /24 range of public IPs for this purpose, because there were a couple of reports of 192.168.254.0/24 conflicting with LAN IP assignments.

Personally I would prefer to add a symbolic hostname like http://android if this was going to be officially supported, so that any future IP reassignments or datapath changes do not break assumptions that are baked into third party apps or documentation.  We could also ask PAC maintainers to ensure that http://android is whitelisted for direct connections.

I'm not sure about Android but Chrome Apps could also listen for connections from outside the device. This isn't something I'm interested in but will likely come up as well.

Just leaving a note here that there is a chrome app that uses chrome.sockets API and lets you setup a TCP forward rule so that an android ARC app with a listenting socket can be seen on the wider LAN:
https://chrome.google.com/webstore/detail/connection-forwarder/ahaijnonphgkgnkbklchdhclailflinn

This looks like a duplicate of #701811, in that they are similar unexpected behaviors; As the reporter of the other one, I would rather that apps installed natively, or under arc, share and behave the same wrt networking. If special behavior is needed, like an isolated internal/public address, then that should be something the apps needs to opt-in to, rather than be the default.

In particular, I wanted the apps installed in ARC to be able to broadcast and respond to broadcast traffic like DLNA, or any discovery protocols. @reaillyg@chromium.org: this is exactly what you say you are not interested in, btw; I'm curios, why not?

@cernekee@chromium.org, this sounds like what you don't want since it would conflict with any existing network services already running.

It also seems strange to introduce a new host-name/alias that could conflict with existing network resolution, unless it is configurable (in a standard way).

As an update, the Android container now has the IP address 100.115.92.2 which is guaranteed to not conflict with anything else because it is owned by Google.

I'm not interested in services being remotely accessible because I'm using this for local web development. The current solution actually introduces an issue because there is no way for me to bind a service that is accessible by Chrome and not by external hosts since it must bind to the container IP and not localhost.

> Connection Forwarder
> I made this app so that I could ssh into termux running on a chromebook without developer mode.

In M62 and above, TCP/UDP IPv4 unicast traffic from the LAN should automatically forward to ARC.  We have an `-m socket` rule that checks to see if the port is open on the Chrome OS side, and if not, NATs the traffic to ARC.

> I would rather that apps installed natively, or under arc, share and behave the same wrt networking

Unfortunately that isn't possible, because they are running under two different OSes which use two different network namespaces.  We try to make it as seamless as possible, but there are "gaps" that affect uncommon use cases like what is described in this ticket.